设计模式之禅：六大设计原则

单一职责原则

单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。

单一职责原则的定义是：应该有且仅有一个原因引起类的变更。原话解释是：There should never be more than one reason for a class to change.

单一职责原则的好处：

• 类的复杂性降低
• 可读性提高
• 可维护性提高
• 变更引起的风险降低

单一职责适用于接口、类，同时也适用于方法。一个方法尽可能做一件事情。

单一职责原则很难在项目中得到体现，因项目需要考虑环境，工作量，人员技术水平等，最终妥协的结果是经常违背单一职责原则。

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

---

里氏替换原则

英文缩写：LSP (Liskov Substitution Principle)。

严格的定义：如果对每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都换成o2时，程序P的行为没有变化，那么类型T2是类型T1的子类型。

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

更通俗的定义：子类可以扩展父类的功能，但不能改变父类原有的功能。
1. 子类必须完全实现父类的方法
2. 子类可以有自己的个性
3. 覆盖或实现父类的方法时输入参数（即方法的形参）可以被放大
4. 覆写或实现父类的方法时输出结果（即方法的返回值）可以被缩小
采用里氏替换原则的目的就是增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。

---

依赖倒置原则

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

采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险提高代码的可读性和可维护性。

依赖的三种写法：

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

我们怎么在项目中使用这个规则呢 ？

• 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
• 变量的表面类型尽量是接口或者是抽象类
• 任何类都不应该从具体类派生
• 尽量不要覆写基类的方法
• 结合里氏替换原则使用

---

接口隔离原则

两层含义：

• 客户端不应该依赖它不需要的接口。
• 类间的依赖关系应该建立在最小的接口上。
  概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。
  接口隔离原则包含以下4层含义：
  接口要尽量小
  根据接口隔离原则拆分接口时，首先必须满足单一职责原则。
  接口要高内聚
  定制服务

接口设计是有限度的

---

迪米特法则

迪米特法则(Law of Demeter， LoD) 也称为最少知识原则。一个对象应该对其他对象有最少的了解。
迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public 变量，尽量内敛，多使用private、 package-private、 protected等访问权限。
如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。
迪米特法则的核心观念就是类间解耦，弱耦合，其结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了难度。

---

开闭原则

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