开放-封闭原则（The Open-Closed Principle)

软件实体（类、模块、函数）应该是可以扩展的，但是不可以修改的。
如果程序中的一处改动就会产生连锁反应，导致一系列的相关模块的改动，那么设计就具有僵化的臭味。如果正确的应用OCP，那么以后再进行同样的改动时，就只需要添加新的代码，而不必改动已经正常运行的代码。

描述

主要两个特征：

“对于扩展是开放的”
模块的行为是可以扩展的，当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。简言之，我们可以改变模块的功能。
“对于更改是封闭的”
对模块进行扩展时，不必改动模块的源代码。

关键是抽象

下图展示了一个简单的不遵循OCP的设计。Client类和Server类都是具体类，Client类使用Server类。如果我们希望Client对象使用另外一个不同的服务器对象，那么就必须要把Client类中使用Server类的地方更改为新的服务器类

下图是根据OCP设计重构的设计

ClientInterface类是一个拥有抽象成员函数的抽象类，Client类使用这个抽象类。如果我们希望Client对象使用一个不同的服务器类，那么只需要冲ClientInterface类派生一个新的类，无需对Client类做任何改动。

Shape应用程序

应用程序中有Circle、Square列表，需求是：绘制他们
从OCP原则考虑，设计方案如下，

class Shape{
draw();
}

class Circle extends Shape{
    draw(){
    
    }
}

class Square extends Shape{
    draw(){

    }
}

Class DrawAllShape{
    void drawAllShapes(List<Shape> lists){
        for(Shape shape :lists){
            shape.draw();
        }
    }
}

根据此设计，如果新增一个Triangle类，只需新增代码即可，无需改动上述代码，达到了开闭原则。真的吗？？？

并非100%封闭

如果需求要求所有圆必须在正方形之前绘制，那么DrawAllShape无法对这种变化做到封闭。要实现这个需求，我们需要修改DrawAllShape，使它首先扫描列表中的圆，然后在扫描所有的正方形。

预测变化和贴切的结构

一般来说，无论模块是多么封闭，都会存在一些无法对之封闭的变化，没有对于所有的情况都贴切的模型。
既然不能完全封闭，就要有策略的对待这个问题，设计人员必须对于他设计的模块应该对哪种变化封闭作出选择，他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。这需要设计人员具备一些从经验中获得的预测能力。
遵循OCP的代价是昂贵的，创建正确的抽象是要花费开发时间和精力的，同时，那些抽象也增加了软件设计的复杂性，开发人员有能力处理的抽象的数量也是有限的，显然，我们希望把OCP的应用限定在可能会发生的变化上。

只受一次愚弄
最初编写代码的时候，假设变化不会发生，当变化发生了，我们就创建抽象来隔离以后发生的同类变化。
刺激变化
尽早查明可能发生的变化，尽早接受变化带来的改变。

Shape改造

class Shape{
    draw();
    //precedes();
    precedes(OrderRule order){
    }
}
Class DrawAllShape{
    sort(list);
    void drawAllShapes(List<Shape> lists){
        for(Shape shape :lists){
            shape.draw();
        }
    }
}

precedes()考虑到枚举排序的话违背了OCP，可以将规则定义起来，改造成precedes(OrderRule order)，排序规则从OrderRule中读取，此时对与Shape绘制顺序的变化不封闭的唯一部分就是OrderRule。

结论

在许多方面，OCP都是面向对象设计的核心所在。遵循这个原则可以的带来面向对象技术所声称的巨大好处（灵活性，可重用性，可维护性）。对于应用程序中的每个部分都肆意的进行抽象同样不是一个好主意。正确的做法是，开发人员应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。