模式之路---设计模式六原则（初篇）

单一职责原则（Single Responsibility Priciple）

定义：一个类只负责一项职责，职责即引起类发生变化的原因。

问题由来：类T负责两个不同职责，职责P1，职责P2。当由于职责P1需求发生改变而需要改变类T时，有可能导致原本运行正常的P2发生故障。

里氏替换原则（Liskov Substitution Priciple）

   定义1：如果对每一个类型为T1的对象O1,都有类型为T2的对象O2，使得以T1定义的所有程序P在所有的对象O1都代换成O2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。

    定义2：所有引用基类的地方必须能透明的使用其子类。

    问题由来：功能P1，由类A完成。现需要将P1进行功能扩展，扩展后的功能为P。其中P由原来功能P1和新功能P2组成。新功能P由A的子类B来完成，则子类B在完成新功能P2的同时有可能改变原有功能P1，发生变化，从而原有功能发生故障。

    遵守里氏替换原则主要注意以下几点：

1.子类可以实现父类抽象方法，但不能覆盖父类非抽象方法。

2.子类中可增加自己特有的方法

3.当子类的方法重载父类的方法时，方法的形参要比父类方法的形参更宽松。

4.当子类的方法实现父类的抽象方法时，方法的返回值要比父类更严格。

把我一个原则子类可以扩展父类的功能，但不能修改父类的功能。

依赖倒置原则（Dependence Inversion Priciple）

定义：高层模块不应该依赖于低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

问题由来：类A直接依赖于类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。在这种情况下，类A一般是高层模块，负责复杂的业务逻辑，类B和类C是低层调用的模块，负责基本的原子操作；假如修改类A，会给程序带来必要风险。

解决方案：将类A修改为依赖接口I ，类B和类C各自实现接口I，类A通过接口I间接与类B与类C发生联系，降低了类与类之间的耦合，从而大大降低修改类A的几率。

补充：依赖倒置原则就是面向接口的编程，他告诉我们，在编程的过程中用抽象代替细节，不要让类与类之间直接发生关系，从而实现高内聚低耦合的编程目的。

接口隔离原则（Interface Segregation Priciple）

定义：客户端不应该依赖他不需要的接口，一个类对另一类的依赖应建立在最小的接口上。

问题由来：类A通过接口I依赖B，类C通过接口I依赖类D，如果接口I对于类A和类C都不是最小接口，则类B和类D必须去实现他们不需要的方法。

解决方案：将臃肿的接口I拆分成几个独立的接口，类A与类C分别与他们需要的接口建立依赖关系，也就是采用该原则。

使用该原则的注意问题：

1.接口尽量小但要有限度。

2.为依赖接口的类定制服务，只暴露给调用的类他需要的方法，他不需要的方法则隐藏起来，只有专注的为一个模块提供定制服务，才能建立最小的依赖关系。

3.提高内聚，减少对外交互，是接口用最少的方法完成最多的事。

迪米特法则（Law of Demeter）

定义：一个对象应该对其他对象保持最少的了解。

问题由来：类与类之间的关系越密切，耦合度越大，当一个类型发生变化时，另一个类影响越大。

解决方案：降低类与类之间的耦合。采用分层管理，不直接与要访问的类发生关系，通过中间类管理或其他抽象接口等方法进行解耦。

开闭原则（Open Close Priciple）

定义：一个软件实体、模块、函数应该对外扩展开放，对修改封闭。

问题由来：在软件的生命周期内，因为变化，升级和维护等原因，需要对源代码进行修改时，可能会对旧代码引入错误，也可能使我们不得不对整个功能进行重构。

开闭原则是始终要遵守的一个原则，他更像是前几个原则的一个总结，只要满足前几个原则就一定满足开闭原则。

设计模式的六大原则告诉我们，用抽象构建框架，用实现扩展细节，用规范约束行为，减少具象之间的沟通。

个人感悟：

将设计模式的原则拿到显示社会中更加容易理解，人与人之间联系的越紧密滋生腐败的可能性越大，但如果具体的人只与抽象的事物打交道，通过抽象来作为连接两者的桥梁，两者之间不见面，这便会大大降低产生腐败的几率。