设计模式-OOD的设计原则(1)-"开-闭原则"
这些OOD原则的一个基石就是"开-闭原则"(Open-Closed Principle OCP).这个原则最早是由Bertrand Meyer提出,英文的原文是:Software entities should be open for extension,but closed for modification.意思是说,一个软件实体应当对扩展开放,对修改关闭.也就是说,我们在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展,换句话说就是,应当可以在不必修改源代码的情况下改变这个模块的行为.
满足OCP的设计给系统带来两个无可比拟的优越性.
具有这两个优点的软件系统是一个高层次上实现了复用的系统,也是一个易于维护的系统.那么,我们如何才能做到这个原则呢?不能修改而可以扩展,这个看起来是自相矛盾的.其实这个是可以做到的,按面向对象的说法,这个就是不允许更改系统的抽象层,而允许扩展的是系统的实现层. 解决问题的关键在:抽象化.我们让模块依赖于一个固定的抽象体,这样它就是不可以修改的;同时,通过这个抽象体派生,我们就可以扩展此模块的行为功能.如此,这样设计的程序只通过增加代码来变化而不是通过更改现有代码来变化,前面提到的修改的副作用就没有了. "开-闭"原则如果从另外一个角度讲述,就是所谓的"对可变性封装原则"(Principle of Encapsulation of Variation,EVP).讲的是找到一个系统的可变因素,将之封装起来.在我们考虑一个系统的时候,我们不要把关注的焦点放在什么会导致设计发生变化上,而是考虑允许什么发生变化而不让这一变化导致重新设计.也就是说,我们要积极的面对变化,积极的包容变化,而不是逃避. [SHALL01]将这一思想用一句话总结为:"找到一个系统的可变因素,将它封装起来",并将它命名为"对可变性的封装原则". "对可变性的封装原则"意味者两点:
"对可变性的封装原则"从工程的角度说明了如何实现OCP.如果按照这个原则来设计,那么系统就应当是遵守OCP的. 但是现实往往是残酷的,我们不可能100%的遵守OCP,但是我们要向这个目标来靠近.设计者要对设计的模块对何种变化封闭做出选择. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |