设计模式 开放封闭原则 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模式体现了这个原则。当然，在设计的初期，不不可能考虑到所有的扩展。在软件的初期，可以假设系统是不会变化的；当变化发生时，要创建抽象类来隔离以后发生的同类变化。对于应用程序中每个部门肆意的抽象也不对，开发人员应该对程序出现频繁变化的哪些部分做出抽象。拒绝不成熟的抽象和抽象本身同样重要。
版权声明：本文为博主原创文章，未经博主允许不得转载。
页:
[1]