OOD的设计基本原则.docVIP

OOD设计基本原则 OCP原则 里氏替换原则 依赖倒置原则 接口隔离原则 聚合与继承原则 单一职责原则 Separation of concerns Principle Pareto Principle (帕雷多原则 80/20原则) Open-Closed Principle 这些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,但是我们要向这个目标来靠近.设计者要对设计的模块对何种变化封闭做出选择. 里氏替换原则 Liskov Substitution Principle 从上一篇的开-闭原则中可以看出,面向对象设计的重要原则是创建抽象化,并且从抽象化导出具体化.这个导出要使用继承关系和一个原则:里氏替换原则(Liskov Substitution Principle, LSP).　　 那么什么是里氏替换原则呢?有个严格的表述,绕口,不好记.还是比较白话的这个好记.说的是:一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它察觉不出基类对象和子类对象的区别.也就是说,在软件里面,把基类都替换成它的子类,程序的行为没有变化.　　 LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为.　　 下面,我们从代码重构的角度来对LSP进行理解.LSP讲的是基类和子类的关系.只有当这种关系存在时,里氏替换关系才存在.如果两个具体的类A,B之间的关系违反了LSP的设计,(假设是从B到A的继承关系)那么根据具体的情况可以在下面的两种重构方案中选择一种.　　 创建一个新的抽象类C,作为两个具体类的超类,将A,B的共同行为移动到C中来解决问题.从B到A的继承关系改为委派关系. 为了说明,我们先用第一种方法来看一个例子。第二种办法在另外一个原则中说明.我们就看那个著名的长方形和正方形的例子.对于长方形的类,如果它的长宽相等,那么它就是一个正方形,因此,长方形类的