设计模式 开放封闭原则 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[i];

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模式体现了这个原则。

当然，在设计的初期，不不可能考虑到所有的扩展。在软件的初期，可以假设系统是不会变化的；当变化发生时，要创建抽象类来隔离以后发生的同类变化。

对于应用程序中每个部门肆意的抽象也不对，开发人员应该对程序出现频繁变化的哪些部分做出抽象。拒绝不成熟的抽象和抽象本身同样重要。