设计模式六原则

一、单一职责原则（SRP）

SRP原话解释：There should never be more than one reason for a class to change.

好处：

1.类的复杂性降低，实现什么职责都有清晰明确的定义。

2.可读性提高。

3.可维护性提高。

4.变更引起的风险降低。变更是必不可少的，如果接口是单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

 

remarks:单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

 

对于单一职责原则，建议接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

 

二、里氏替换原则（LSP）

只要父类能出现的地方子类都可以出现，而且替换为子类也不会产生任何错误或异常，使用者可有根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必能适应。

优点：

1.代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性。

2.提高代码的重用性。

3.子类可以形似父类，但又异于父类。

4.提高代码的可扩展性，实现父类的方法就可以“为所欲为”了。君不见很多开源框架的扩展接口都是通过继承父类来完成的。

5.提高产品或项目的开放性。

 

缺点：

1.继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法。

2.降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束。

3.增强了耦合性。当父类的常量、变量和方法被修改时，必需要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的结果——大片的代码需要重构。

 

四大规范：

1.子类必须完全实现父类的方法。（如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承）

2.子类可以有自己的个性。

3.覆盖或实现父类的方法时输入参数可以被放大，但不能缩小。

4.覆写或实现父类的方法时输出结果可以被缩小，但不能放大。

 

 

三、依赖倒置原则(DIP)

含义：

1.高层模块不应该依赖低层模块，两者都应该依赖其抽象。

2.抽象不应该依赖细节。

3.细节应该依赖抽象。

（在JAVA,PHP中，抽象就是指接口或抽象类，两者都是不能直接被实例化的。细节就是实现类）

精简的定义就是“面向接口编程”——OOD（Object-Oriented Design,面向对象设计）的精髓之一。

 

优点：

1.减少类间的耦合性。

2.提高系统的稳定性。

3.降低并行开发引起的风险。

4.提高代码的可读性和可维护性。

 

依赖的三种写法：

1.构造函数传递依赖对象。

2.setter方法传递依赖对象。

3.接口声明依赖对象。

 

规范：

1.每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。

2.变量的表面类型尽量是接口或者是抽象类。

3.任何类型都不应该从具体类派生。

4.尽量不要覆写基类的方法。

5.结合里氏替换原则使用。

 

四、接口隔离原则(ISP)

建立单一接口，不要建立臃肿庞大的接口。接口隔离原则与单一职责的审视角度是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。

 

优点：可以预防未来变更的扩散，提高系统的灵活性和可维护性。

 

含义：

1.接口要尽量小。

2.接口要高内聚。（高内聚就是提高接口、类、模块的处理能力，减少对外的交互）

3.定制服务。

4.接口设计是有限度的。（接口的设计粒度越小，系统越灵活，但是灵活的同时也带来了结构的复杂化，开发难度的增加，可维护性降低）

 

实现规则：

1.一个接口只服务于一个子模块或业务逻辑。

2.通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法。

3.已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理。

4.了解环境，拒绝盲从。

 

五、迪米特法则(LoD，也称最少知识原则)

 一个对象应该对其他对象有最少的了解。

 

含义：

1.只和朋友交流（出现在成员变量、方法的输入输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友类）

2.朋友间也是有距离的。（类尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、protected等访问权限）

3.是自己的就是自己的。

4.谨慎使用Serializable。

 

在实际应用中，如果一个类跳转两次以上才能访问到另一个类，就需要想办法进行重构了。跳转的次数越多，系统越复杂，维护就越困难。

 

 

六、开闭原则（OCP 精髓）

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。但并不意味着不做任何修改，低层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。

 

优点：

1.单元测试更加方便，而不影响现有逻辑

2.提高代码的复用性。

3.提高可维护性。

4.面积对象开发的要求。

 

实践方法：

1.抽象约束：

（1）通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法。

（2）参数类型、引用对象尽量使用接口或者抽象类，而不是实现类

（3）抽象层尽量保持稳定，一旦确定即不允许修改。

 

2.元数据(metadata)控制模块行为（元数据就是用来描述环境和数据的数据，通俗地说就是配置参数，参数可以从文件中获得，也可以从数据库中获得）

3.制定项目章程

4.封装变化

（1）将相同的变化封装到一个接口或抽象类中

（2）将不同的变化封装到不同的接口或抽象类中