软件实体(类、模块、函数等等)应该是可以扩展，但是不可修改的。
这里的所有观点摘抄自《敏捷软件开发原则、模式与实践》，原著Robert C. Martin，邓辉等译。
开放-封闭原则
如果程序中的一处改动会引起系统多个相关模块的改动，那么这个设计就是一个僵化的设计。从OCP的角度，我们应该对这个系统进行重构，以便拥抱变化。
开放-封闭原则设计出的模块，有两个重要的特征：
- 对扩展开放
这怎么理解，例如我们想要去潜水，那么我们并不是把我们的脚，压成鸭子一样的蹼。而是穿上脚蹼。
用书上的话说就是模块的行为可以扩展，当应用需求发生变化时，我们可以对模块进行扩展。
- 对修改封闭
我们不想像金刚狼那样，使得我们的身体变成金属。我们宁愿像钢铁侠，可以穿一身金属。
也就是对模块的源代码不进行修改，变化到来时，只需要利用扩展即可。
该如何来做
理论讲完了，那么该如何实现OCP呢？
很简单，就是将变化的部分，作为扩展进行抽象。为什么是抽象，而不是具体某个实现呢？主要我们需要应对变化，既然是变化，就无法和具体的实现对应起来，
所以需要一个抽象的模糊的部分来描述变化的部分。
类比于人类的脚，我们需要应对各种变化（如爬山、跑步等运动方式或者宴会、出行等场合）。所以需要对修改我们的脚封闭，对各种变化的场景扩展，结果是穿上
鞋子--抽象。
OCP常用的方式：
- 组合
听起来是非常基本的OO的概念，但是应用到OCP中来，却需要特别的关注。
正如刚才的例子，我们的脚有鞋子这个抽象，这样在爬山时，我们就可以穿上具体的登山鞋，来完成登山这项运动。
书里面的例子，client类使用了一个抽象类Client Interface，这样具体的client对象就可以使用一个具体的server对象，来实现功能。当我们需要使用不同
的server的时候，只需要替换对应的具体的server对象即可。
- 继承
书中的例子，Policy类预留了具有某种行为的抽象接口。这样在实际使用中，如果需要应对某种变化的Policy，则可以通过派生类的方式来应对。即在派生类中实现
应对变化的具体行为。在C++中，这种方式表现为纯虚函数，JAVA中表现为抽象方法。
在这里是通过继承的方式，来对基类修改进行封闭，对扩展开放。
违反OCP的例子
此例子是书上的例子，比较有代表性，使用的是C语言，并且没有遵循OCP的设计原则。
void DrawAllShape(ShapePointer list[], int n)
{
int i;
for (i = 0; i < n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break;
case circle:
DrawSquare((struct Circle*)s);
break;
default:
break;
}
}
这个例子符合OCP么？只需要看它是如何应对变化的。
假如我们需要新增一个三角形，就必须在这段代码的switch语句中新增case。这样就导致我们修改了源代码，也就违反了OCP所说的对修改封闭。
这个例子所带来的危害也是显而易见的：
- 新增一种类型，都需要新增switch（或者if/else）。
- 如果switch（if/else）过于复杂，那么要理解和新增新的形状就非常困难了。
- 对于形状的类型，也需要对ShapeType enum进行修改，这样就会到这所有用到ShapeType enum的地方，都进行重新编译。也就是新增一个类型，所有类型
相关的代码都要重新被编译一次。
遵循OCP的例子
还是针对shape的这个应用场景，下面的代码给出了C++的遵循OCP的方式：
class Shape
{
public:
virtual void Draw() const = 0;
}
class Square: public Shape
{
public:
virtual void Draw() const;
}
class Circle: public Shape
{
public:
virtual void Draw() const;
}
void DrawAllShapes(vector<Shape*>& list)
{
vector<Shape*>::iterator I;
for (i = list.begin(): i != list.end(); i++)
{
(*i)->Draw();
}
}
这段代码究竟是不是符合OCP的原则，我们新增一个新的类型来试试。假如需要增加一个三角形，我们只需要增加一个继承自Shape的Triangle类型。在使用
DrawAllShapes的地方，将Triangle的对象存入list即可。从这里可以看出，我们并未对上述的代码逻辑进行修改。而是从Shape扩展出Triangle的类型。
也就实现了对修改封闭，对扩展开放的原则。
应对变化的思维
世界上并没有绝对的事情，对于OCP原则也是，即使我们满足了目前的变化，使得设计相对稳定，但也会出现使得OCP不满足的变化发生。你有可能觉得很沮丧，费
了半天劲，实现了对修改封闭对扩展开放，却发现还是有变化会导致代码的修改。
其实，我们提到了，我们需要应对变化，而不能避免所有的变化。我们的系统是一个相对稳定的系统而不是绝对稳定的系统。
那么我们该如何去做，是否需要考虑所有的可能变化的情况，对其使用OCP原则，创建一个雷打不动的系统。其实不是。你永远不可能预测到所有的变化是什么样子，
就像诺基亚公司兴盛的时候，谁也没想到它会以何种方式，以何种速度倒下。
到底该如何来做呢？书中提到如下几个方法：
- 同一类型的变化只会导致我们修改一次代码设计。
- 刺激变化及早发生。这里面可以使用测试驱动开发，缩短迭代周期，showcase等方式来尽早暴露出变化。
- 将变化的部分，尽可能的抽象出来。
