设计模式遵循的规则

一、单一职责原则（SRP：Single responsibilityprinciple又称单一功能原则，面向对象五个基本原则（SOLID）之一）

 一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离。
      好处：
1.类的复杂性降低，实现什么职责都有清晰明确的定义。
2.可读性提高。
3.可维护性提高。
 4.变更引起的风险降低。变更是必不可少的，如果接口是单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

           

单一职责原则的原理：

如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强内聚性。
 

二、里氏替换原则（Liskov Substitution Principle LSP任何基类可以出现的地方，子类一定可以出现，使用者可以根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必能适应。）

 优点：

1.代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性。
2.提高代码的重用性。
3.子类可以形似父类，但又异于父类。
4.提高代码的可扩展性，实现父类的方法就可以“为所欲为”了。君不见很多开源框架的扩展接口都是通过继承父类来完成的。
5.提高产品或项目的开放性。

 

缺点：

1.继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法。
2.降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束。
3.增强了耦合性。当父类的常量、变量和方法被修改时，必需要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的结果——大片的代码需要重构。

 

四大规范：

1.子类必须完全实现父类的方法。（如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承）
2.子类可以有自己的个性。
3.覆盖或实现父类的方法时输入参数可以被放大，但不能缩小。
4.覆写或实现父类的方法时输出结果可以被缩小，但不能放大。

 

三、依赖倒置原则（DIP：Dependence Inversion Principle）是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

含义：

 

1.高层模块不应该依赖低层模块，两者都应该依赖其抽象。
2.抽象不应该依赖细节。
3.细节应该依赖抽象。
（在JAVA,PHP中，抽象就是指接口或抽象类，两者都是不能直接被实例化的。细节就是实现类）
精简的定义就是“面向接口编程”——OOD（Object-OrientedDesign,面向对象设计）的精髓之一。

 

优点：

 

1.减少类间的耦合性。
2.提高系统的稳定性。
3.降低并行开发引起的风险。
4.提高代码的可读性和可维护性。

 

依赖的三种写法：

 

1.构造函数传递依赖对象。
2.setter方法传递依赖对象。
3.接口声明依赖对象。

 

规范：

 

1.每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。
2.变量的表面类型尽量是接口或者是抽象类。
3.任何类型都不应该从具体类派生。
4.尽量不要覆写基类的方法。
5.结合里氏替换原则使用。

 

四、接口隔离原则(ISP：Interface Segregation Principle)

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

 

优点：

 

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

 

含义：

 

1.接口要尽量小。
2.接口要高内聚。（高内聚就是提高接口、类、模块的处理能力，减少对外的交互）
3.定制服务。
4.接口设计是有限度的。（接口的设计粒度越小，系统越灵活，但是灵活的同时也带来了结构的复杂化，开发难度的增加，可维护性降低）

 

实现规则：

 

1.一个接口只服务于一个子模块或业务逻辑。
2.通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法。
3.已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理。
4.了解环境，拒绝盲从。

 

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

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

 

含义：

 

1.只和朋友交流（出现在成员变量、方法的输入输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友类）
2.朋友间也是有距离的。（类尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、protected等访问权限）
3.是自己的就是自己的。
4.谨慎使用Serializable。
 
在实际应用中，如果一个类跳转两次以上才能访问到另一个类，就需要想办法进行重构了。跳转的次数越多，系统越复杂，维护就越困难。

 

 

六、开闭原则（OCP：Open Closed Principle）

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

 

优点：

 

1.单元测试更加方便，而不影响现有逻辑
2.提高代码的复用性。
3.提高可维护性。
4.面积对象开发的要求。

 

实践方法：

 

1.抽象约束：

 

（1）通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法。
（2）参数类型、引用对象尽量使用接口或者抽象类，而不是实现类
（3）抽象层尽量保持稳定，一旦确定即不允许修改。

 

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

 

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