开放-封闭原则(Open Close Principle: OCP)

软件实体(类、模块、函数等等)应该是可以扩展，但是不可修改的。

这里的所有观点摘抄自《敏捷软件开发原则、模式与实践》，原著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& list)
{
    vector::iterator I;
    for (i = list.begin(): i != list.end(); i++)
    {
        (*i)->Draw();
    }
}

这段代码究竟是不是符合OCP的原则，我们新增一个新的类型来试试。假如需要增加一个三角形，我们只需要增加一个继承自Shape的Triangle类型。在使用
DrawAllShapes的地方，将Triangle的对象存入list即可。从这里可以看出，我们并未对上述的代码逻辑进行修改。而是从Shape扩展出Triangle的类型。
也就实现了对修改封闭，对扩展开放的原则。

应对变化的思维

世界上并没有绝对的事情，对于OCP原则也是，即使我们满足了目前的变化，使得设计相对稳定，但也会出现使得OCP不满足的变化发生。你有可能觉得很沮丧，费
了半天劲，实现了对修改封闭对扩展开放，却发现还是有变化会导致代码的修改。

其实，我们提到了，我们需要应对变化，而不能避免所有的变化。我们的系统是一个相对稳定的系统而不是绝对稳定的系统。

那么我们该如何去做，是否需要考虑所有的可能变化的情况，对其使用OCP原则，创建一个雷打不动的系统。其实不是。你永远不可能预测到所有的变化是什么样子，
就像诺基亚公司兴盛的时候，谁也没想到它会以何种方式，以何种速度倒下。

到底该如何来做呢？书中提到如下几个方法：

同一类型的变化只会导致我们修改一次代码设计。
刺激变化及早发生。这里面可以使用测试驱动开发，缩短迭代周期，showcase等方式来尽早暴露出变化。
将变化的部分，尽可能的抽象出来。

开放-封闭原则(Open Close Principle: OCP)

软件实体(类、模块、函数等等)应该是可以扩展，但是不可修改的。