设计模式 开放封闭原则 OCP

色破飞机

　　OCP开放封闭原则。
开放：类/模块是可扩展的，可以增加新的行为封闭：类/模块是封闭的，代码是不可修改的。
不好的例子：假如 有一批shape，比如 Circle Square，定义一个绘制函数，如果不是oop，则基本实现如下：struct Share{     Type shapeType;}struct Circle{     Type shapeType;     double itsRadius;     Point point;};struct Square{Type shapeType;double side;Point itsTopleft;};typedef Shape* ShapePointer;void DrawAllShapes(ShapePointer list[], int n){    int i  = 0;     for (; i < n; i++)    {          struct Shape*s = list;          switch(s->shapeType)          {               case square:                    do something;               case circle:                    do something;           }     }}这里显然不满足OCP，当我们增加一个Shape时，必须修改这个接口，增加case。同时可能有很多基于shape的接口，比如计算面积等等，增加Shape时，需要每个地方都做修改，维护很难。同时需要编译所有使用这些接口的模块。遵循OCP的设计。class Shape{virtual void Draw() const = 0;};class Square : public Shape{void Draw() const;};class Circle : public Shape{void Draw() const;};void DrawAllShapes(vector<Shape*>& list){    vector<Shapre*>::iterator iter = list.begin();     for(; iter != list.end(); ++iter)          (*iter)->Draw();}这样，当增加一个新的shape时，只需要从shape继承，并override，这样不改变接口(封闭)，增加新的功能(开放).基本理念：抽象Strategy 模式 以及Template模式体现了这个原则。当然，在设计的初期，不不可能考虑到所有的扩展。在软件的初期，可以假设系统是不会变化的；当变化发生时，要创建抽象类来隔离以后发生的同类变化。对于应用程序中每个部门肆意的抽象也不对，开发人员应该对程序出现频繁变化的哪些部分做出抽象。拒绝不成熟的抽象和抽象本身同样重要。
             版权声明：本文为博主原创文章，未经博主允许不得转载。