敏捷开发之原则 五大原则 SRP OCP LSP DIP ISP

一、面向对象设计原则

内容来自《敏捷开发：原则、模式与实例》

SRP单一职责原则（Single Responsibility Principle）：
　　就一个类而言，应该仅有一个引起它变化的原因。
OCP开放-封闭原则（Open Closure Principle）：
　　软件实体（类，模块，函数等）应该可以扩展的，但不可修改。
LSPLiskov 替换原则（Liskov Substitution Principle）：
　　子类型必须能够替换它们的基类型
DIP依赖倒置原则（Dependence Inversion Principle）：
　　抽象不应该依赖于细节，细节应该依赖于抽象。
ISP接口隔离原则（Interface Segregation Principle）：
　　不应该强迫客户依赖与它们不用的方法。接口属于客户，不属于它所在的类层次结构。
REP重用发布等价原则（Release Reuse Equivalency Principle）：
　　重用粒度就是发布粒度。
CCP共同封闭原则（Common Closure Principle）：
　　包中 所有类应该对于同一类性质的变化应该是共同封闭的。一个变化若对包产生影响，则将对包中所有的类产生影响。而对其它的包不造成影响。
CRP共同重用原则（Common Resue Principle）：
　　一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
ADP无环依赖原则（Acyclic Dependencies Principle）：
　　在包的依赖关系图中不允许存在环。
SDP稳定依赖原则（Stable Dependencies Principle）：
　　易变化包不应该依赖稳定包。
SＡP稳定抽象原则（Stable Abstract Principle）：
　　朝着抽象方向扩展。

二、SRP原则

　　每个变化就是类的一个职责。当需求发生变化时，对应的反映为职责的变化。如果一个类承担多个职责，那么引起类变化的原因就有多个，等于就把这些职责耦合化了。
　　如下图Rectangle类两个方法draw()和area()。初一看认为都是属于Rectangle的，但是考虑到用途时就会发现，如果一个应用只是用到图形计算area()的话，GUI绘画draw()就是多余的；反之亦然。违反了SRP原则。

　　因此我们应该将不同职责分开来，这样对Geometry Rectangle的修改就不会影响到Rectangle的应用。

　　有人会说，万一这两种职责都需要用到呢？使用时岂不是麻烦。这是我们使用一种折中方法,使用接口实现解耦：

三、OCP原则

　　开放-封闭原则中开放是指对扩展开放，封闭是指不必对原有模块进行修改。也就是说，当需求发生变化时，我们只需要添加新的模块，而无需修改原有代码。
　　如下代码，已有Circle，Square。当我们需要添加一个新的图形时就会出行问题，涉及到shape，drawAllShape中修改。违反了OCP原则，修改了原有代码。因为添加新的Rectangle类导致shape，circle，Square等需要重新编译，部署。

　　遵循OCP原则，我们可以将其共同部分抽象化，将不同部分写在继承的子类中。

　　但是这只是对一种变化封闭了。当我们产生另一种变化，比如我们需要先画圆，再按顺序画其他图形这是，drawAllShape就不再是封闭的了。因此，在设计中，开发人员需要预测最可能的变化。但是如果事先设置许多吊钩，最后又没用到，会需要花很多精力去维护。最好办法是尽快开发，缩短迭代周期来刺激变化产生。如果只是对两个图形排序可以：


　　而如果需要对多种图形排序，可采用表驱动（数据驱动）：

四、LSP原则

　　liskov替换要求子类型能够替换基类型。如果不能替换，导致将子类型赋值给基指针时导致开发者错误以为该指针指的是基类，错误使用基类中有，而子类中没有的方法，导致错误。
下述代码由于子类型无法替换父类型，导致DrawShape函数需要知道Shap的所有子类型。违反LSP后导致违反OCP。

五、DIP原则

　　依赖倒置原则：高层模块不依赖底层模块，二者依赖抽象；抽象不依赖细节，细节依赖抽象。如果高层依赖底层，导致底层的修改影响到高层，这是不应该的。高层属于业务逻辑层。而且由于依赖底层，导致高层重用比较困难。


　　上图的依赖违反DIP原则。我们可以通过抽象化将高层独立出来，翻转依赖关系如下图：

　　另类巧妙的违反，下述代码Square继承Rectangle，且Square类中巧妙的修改函数，达到正方形长宽相等的要求。

　　但是如果开发者不知传递的是Square，而以为是Rectangle是发生断言错误。如下图：

　　关于这方面有个Eiffle语言的契约设计（Design By Contract）：契约是指每个方法有一个前置条件和后置条件。要想方法执行，必须满足前置条件，方法执行后，后置条件必须为真。如下：

　　而当通过抽象基类使用派生类时派生类方法的前置条件要<=（弱）基类；后置条件要>=（强）基类。

六、ISP原则

　　在使用过程中有时候为了达到某种目的，过分使用接口继承，从而为了满足一个子类型的功能而导致其他子类产生接口污染。
如下图，为了完成TimedDoor的定时提醒功能，在基类Door上基础类一个接口，接口中timeOut()对于TimedDoor类有需要，而对于其他Door子类完全没有必要。

　　一种方法是通过委托分离接口：
当TimedDoor需要注册一个超时请求时，新建一个Timer和DoorTimerAdapter对象，委托DoorTimerAdapter对象，并将DoorTimerAdapter对象注册到Timer中，当Timer对象发送timeout()消息给DoorTimerAdapter对象时，DoorTimerAdapter对象再把消息发给TimedDoor。

　　另一种使用多重继承：

七、五大原则速记

　　认识五大原则后，我们发现前三个原则（SRP，OCP，LSP）针对的是某一个责任类的设计；而后两个原则（DIP，ISP）则是针对不同责任类之间的依赖关系。

八、包原则：REP CCP CRP ADP SDP SAP

　　REP重用发布等价原则：对于包得到重用时，应该能够得到原作者一定时间的支持维护。重用粒度与发布粒度等价。
　　
　　CCP共同封闭原则：一个变化能够对包内所以类产生影响，但不会对其他包产生影响。
　　
　　CRP共同重用原则：当对一个包重用时，就要重用包内所有类。
　　
　　ADP无环依赖原则：将一个项目分给多个包，包之间的依赖不可产生一个环，如此导致循环的工作。解决办法：1、使用依赖倒置原则反转依赖关系；2、将成环两个包中共同部分拆分除去形成一个新包，依赖新包。　
　　
　　SDP稳定依赖原则：各个包的稳定性各有不同，一般情况下，使用不稳定包依赖稳定性高的包。　
　　
　　SAP：稳定抽象原则：一个稳定的包应该是抽象的，这样就能够对其进行扩展，不会因为其稳定性而过分限制设计；而一个不稳定的包应该是具体的，这样使得内部代码容易修改。　
　　
　　同样，包的前三个原则（REP、CCP、CRP）关注的是包的内聚性，帮助我们将类分包；而后三个原则（ADP、SDP、SAP）关注的是包的耦合性，帮助我们确定包之间关系。