【设计模式之禅】六大原则的解读

一.六大原则的解读

1.单一职责原则

Single Responsibility Principle

解释：

There should never be more than one reason for a class to change.

单一职责原则要求一个接口或类只有一个原因引起变化，也就是一个接口或类只有一个职责，他就负责一件事。一个职责就是一个接口。

好处：

（从上到下还是因果的）

• 类的复杂程度降低，职责清晰
• 可读性提高，不复杂当然好读啦~
• 可维护性提高，简单好读当然好维护啦~
• 风险降低，好维护的话出错风险就低啦~

实践：

“This is sometimes hard to see”

单一职责受到非常多因素的制约。

很难实现，但是最好做到接口一定要单一职责，类的设计也做到只有一个原因引起变化

2.里氏替换原则

Liskov Substitution Principle

解释：

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

所有引用基类的地方必须能透明地使用其子类的对象。

简单来说就是父类能出现的地方子类都可以出现，但是反之则不行

实践：

• 尽量避免子类的特有方法或属性；因为当把子类当父类来用就委屈了子类的“个性”；把子类当作一个独立业务，就会让代码之间的耦合关系变得模糊。

3. 依赖倒原则

Dependence Inversion Principle

解释：

DIP: High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

• 高层模块不应该依赖底层模块，两者都应该依赖其抽象。
• 抽象不应该依赖细节。
• 细节应该依赖抽象。

在JAVA 中的体现：

• 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
• 接口或抽象类不依赖于实现类。
• 实现类依赖与接口或抽象类。

实践：

• 每个类尽量都有接口或抽象类，或者两者都具备。
• 变量的表面类型尽量是接口或者是抽象类。 ？
• 任何类的父类都不能是具体实现类
• 尽量不要@Override父类的方法
• 结合LSP使用：接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的世界对父类进行细化。

4.接口隔离原则 （个人很受用）

Interface Segregation Principle

两种接口类型：

1. 实例接口（Object Interface），在Java中声明一个类，然后用new关键字产生一个实例，它是对一个类型的事物的描述，就是一种接口, 它不应该依赖它不需要的接口。

2. 类接口（Class Interface），Java中经常使用的interface关键字定义的接口，类间的依赖关系应该建立在最小的接口上。

与单一职责原则的区别：

单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑的划分，而接口隔离原则要求接口的方法尽量少。一个职责可能包含10个方法，这10个方法都放到一个接口中，但不同模块分别只访问其中几个。

实践：

• 一个接口只服务于一个子模块或业务逻辑；
• 通过业务逻辑压缩接口中的public方法；
• 已经被污染了的接口，尽量去修改，若更改的风险较大，则采用适配器模式进行转化处理；
• 了解环境，拒绝盲从，深入了解业务逻辑才能设计出好接口。

5.迪米特法则

Law of Demeter

或者叫最少知识原则

Least Knowledge Principle

解释：

• 只和朋友交流：两个对象之间的耦合就成为朋友关系，他俩直接通信
• 朋友间也是有距离的 ：不能暴露过多的方法给友类
• 是自己的就是自己的 ：如果一个方法放在本类中不会增加类间关系，也不会产生影响，那就放在本类中。

实践：

• 核心观念：类间解耦，弱耦合；
• 为了弱耦合，就需要产生许多跳转类；
• 适度考虑该原则，不需要过度执行，免得过犹不及。

6.开闭原则 (重点)

是上面五项原则的指导与终极目标！

解释：

Software entities like classes, modules and functions should be open for extension but closed for modifications.

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。一个软件实体（模块、类、接口、方法）应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

实践：

• 抽像约束 ： 通过接口或抽象类约束一组变化的行为，并对拓展开放。
• 元数据控制模块行为 ：利用配置参数来控制
• 制定项目章程
• 封装变化：把相同的变化封装到一个接口或抽象类；把不同的变化封装到不同的接口或抽象类。