满足OCP的设计给系统带来两个无可比拟的优越性.
- 通过扩展已有的软件系统,可以提供新的行为,以满足对软件的新需求,使变化中的软件系统有一定的适应性和灵活性.
- 已有的软件模块,特别是最重要的抽象层模块不能再修改,这就使变化中的软件系统有一定的稳定性和延续性.
具有这两个优点的软件系统是一个高层次上实现了复用的系统,也是一个易于维护的系统.那么,我们如何才能做到这个原则呢?不能修改而可以扩展,这个看起来是自相矛盾的.其实这个是可以做到的,按面向对象的说法,这个就是不允许更改系统的抽象层,而允许扩展的是系统的实现层.
解决问题的关键在:抽象化.我们让模块依赖于一个固定的抽象体,这样它就是不可以修改的;同时,通过这个抽象体派生,我们就可以扩展此模块的行为功能.如此,这样设计的程序只通过增加代码来变化而不是通过更改现有代码来变化,前面提到的修改的副作用就没有了.
"开-闭"原则如果从另外一个角度讲述,就是所谓的"对可变性封装原则"(Principle of Encapsulation of Variation,EVP).讲的是找到一个系统的可变因素,将之封装起来.在我们考虑一个系统的时候,我们不要把关注的焦点放在什么会导致设计发生变化上,而是考虑允许什么发生变化而不让这一变化导致重新设计.也就是说,我们要积极的面对变化,积极的包容变化,而不是逃避.
[SHALL01]将这一思想用一句话总结为:"找到一个系统的可变因素,将它封装起来",并将它命名为"对可变性的封装原则".
"对可变性的封装原则"意味者两点:
- 一种可变性应当被封装到一个对象里面,而不应当散落到代码的很多角落里面.同一种可变性的不同表象意味着同一个继承等级结构中的具体子类.继承应当被看做是封装变化的方法,而不应当是被认为从一般的对象生成特殊的对象的方法(继承经常被滥用).
- 一种可变性不应当与另外一种可变性混合在一起.从具体的类图来看,如果继承结构超过了两层,那么就意味着将两种不同的可变性混合在了一起.
"对可变性的封装原则"从工程的角度说明了如何实现OCP.如果按照这个原则来设计,那么系统就应当是遵守OCP的.
但是现实往往是残酷的,我们不可能100%的遵守OCP,但是我们要向这个目标来靠近.设计者要对设计的模块对何种变化封闭做出选择.
