“开-闭”原则

        “开-闭”原则讲的是：一个软件实体应当对扩展开放，对修改关闭。

         英文原文是：Software entities should be open for extension, but closed for modification.
        这个原则说是，在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。换言之，应当可以在不必修改源代码的情况下改变这个模块的行为。
        这话听上去好像是矛盾的，但是实际上本书将在后面给出的几个面向对象的设计原则和设计模式中很具体的说明如何在设计上做到这一点。
        所有的软件系统都有一个共同的性质，即对它们的需求都会随时间的推移而发生变化。在软件系统面临新的需求时，系统的设计必须时稳定的。满足“开-闭”原则的设计可以给一个软件系统两个无可比拟的优越性：
                1、通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求，使变化中的软件系统有一定的适应性和灵活性。
                2、已有的软件模块，特别是最重要的抽象模块不能再修改，这就是使变化中的软件系统有一定的稳定性和延续性。
        具有这两上优点的软件系统是一个在高层次上实现了复用的系统，也是一个易于维护的系统。

        抽象化是关键
        解决问题的关键在于抽象化。在像Java语言这样的面向对象的编程语言里面，可以给系统定义出一个一劳永逸、不再更改的抽象设计，此设计允许有无穷无尽的行为在实现层被实现。在Java语言里，可以给出一个或多个抽象Java类或Java接口，规定出所有的具体类必须提供的方法特征（Signature）作为系统设计的抽象层。这个抽象层预见了所有的可能扩展，因此，在任何扩展情况下都不会改变。这就使得系统的抽象层不需修改，从满足了“开-闭”原则的第二条：对修改关闭。
        同时，由于从抽象层导出一个或多个新的具体类可以改变系统的行为，因此系统的设计对扩展是开放的，这就满足了“开-闭”原则的第一条。
        关于在Java语言中实现抽象化的方法，请阅读后面的“专题：Java接口”一章和“专题：抽象类”一章。
        对可变性的封装原则
        “开-闭”原则如果从另外一角度讲述，就是所谓的“对可变性的封装原则”（Principle of Encapsulation of Variation，常常略写做EVP）。“对可变性的封装原则”讲的是找到一个系统的可变因素，将之封装起来。
        在[GOF95]中说：考虑你的设计中什么可能会发生变化。与通常焦点放到什么会导致设计改变的思考方式正好相反，这一思路考虑的不是什么会导致设计改变，而是考虑你充许什么发生变化而不让这一变化导致重新设计。
        [SHALL01]将这一思想用一句话总结为：“找到一个系统的可变因素，将它封装起来”，并将它命名为“对可变性的封装原则”。
        “对可变性的封装原则”意味着两点：
                1、一种可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里面。同一种可变性的不同表象意味着同一个继承等级结构中的具体子类，因此，读者可以期待在设计模式中看到继承关系。
                继承应当被看做是专卖店装变化的方法，而不应当被认为是从一般的对象生成特殊的对象的方法[SHALL01]。
                2、一种可变性不应当与另一种可变性混合在一起。如果读者留心本书所研究的这些设计模式的类图的话，就会发现所有类图的继承结构一般都不会超过两层，不然就意味着将两种不同的可变性混合在一起了。
        显然，“对可变性的封装原则”从工程的角度讲解了如何实现“开-闭”原则。如果能够将“对可变性的封装原则”作为总的设计原则的话，那么按照这个原则进行的系统设计，应当遵守“开-闭”原则。
        尽管在很多情况下，无法百分之百地做到“开-闭”原则，但是如果向这个方向上的努力能够得到部份的成功，也可以显著地改善一个系统的结构。