设计模式（一）：6大设计原则

1. 单一职责原则

规则应用：类与接口的功能、职责应该单一，不要将过多的功能与职责都写在一个类、一个方法里。

 

2. 里氏替换原则

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

（1）子类必须完全实现父类的方法

即父类的方法的功能，子类都应该有。不能出现，父类有一个方法，子类不能实现，或者实现了就违背逻辑。如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子或集成关系，采用依赖、聚集、组合等关系代替继承。

（2）子类可以有自己的个性

即子类可以有自己特有的方法。

（3）覆盖或实现父类的方法时输入参数可以被放大

例如（重载中）子类的方法中的输入参数有一个A类，父类同名方法的输入参数也有一个B类，A类应该是B类的父类。待补充...

（4）覆盖或实现父类方法是输出结果可以被缩小

待补充...

 

3. 依赖倒置原则

含义：

• 高层模块不应该依赖低层模块，两者都应该依赖其抽象类；模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生。
• 接口或抽象类不应该依赖细节（实现类）；
• 细节应该依赖抽象类（即实现类依赖接口或抽象类）

具体一点：

一个实现类不能直接调用另外一个实现类的方法时，而应该是前者的抽象类与后者的抽象类建立依赖关系来产生（即前者的抽象类调用后者的抽象类的方法）。

补充原则：

• 每个类尽量都有接口或抽象类，或者抽象类和接口都具备
• 变量的表面类型尽量是接口或者抽象类
• 任何类都不应该从具体类派生（继承尽量不要超过两层）
• 尽量不要覆写基类的方法（如果基类是抽象类，而且这个方法已经实现了，子类尽量不要覆写）

 

4. 接口隔离原则

核心：接口尽量细化，同时接口中的方法尽量少。

注：单一职责要求类和接口职责单一，注重的是职责，这是业务逻辑的划分，而接口隔离原则要求接口的方法尽量少。

 

5. 迪米特法则/最小知识原则

规则解释：一个对象应该对其他对象有最小的了解。

核心观念：类间解耦，弱耦合。

规则应用：

（1）一个类只与直接的朋友类交流。

朋友类的定义：出现在成员变量、方法的输入输出参数中的类。

即一个类的方法中只允许成员变量、输入输出参数中的类出现，不应出现其他的类型的类。

（2）保持朋友类间的距离

即一个类的方法中，不应过多调用朋友类的不同的public方法，朋友类不要暴露过多方法给其他类，应该将一些实现在自身的类中封装起来，将一些public方法改为private，减少public的方法和属性。应该使到一个类只需调用朋友类尽量少的public方法即可实现该有的功能。

（3）如果一个方法放在本类中，既不增加类间关系，对本类也不产生负面影响，那就放置在本类中。

 

6. 开闭原则

含义：软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。