设计模式之禅2 笔记（一）

设计模式之禅2 笔记（一）

六大设计原则解读

• 单一职责原则
• 里氏替换原则
• 依赖倒置原则
• 接口隔离原则
• 迪米特法则
• 开闭原则

单一职责原则（Single Responsibility Principle，简称是SRP)

定义
应该有且仅有一个原因引起类的变更。
There should never be more than one reason for a class to change.

单一职责原则有什么好处： 简单
● 类的复杂性降低，实现什么职责都有清晰明确的定义。
● 可读性提高，复杂性降低，那当然可读性提高了。
● 可维护性提高，可读性提高，那当然更容易维护了。
● 变更引起的风险降低，变更是必不可少的，一个接口修改只对相应的实现类有影响，对其他的接口无影响。

设计上怎么做到单一职责呢？即如何避免多个原因引起类的变更？
1. 类的职责要单一，避免出现功能大而全的类。
2. 接口的职责要单一，多个接口避免相互影响。

按职责细分，需要有个度，这个度需要设计者根据实际项目去衡量。细分职责，职责更单一，但是带来的后果是类和接口的数量快速膨胀，之间的关系增多也增加了复杂度，使项目难以维护。

书中也提到了单一职责也适用于方法，降低方法的复杂度，定义接口时需要参考。

　里氏替换原则（Liskov Substitution Principle，LSP）

两种定义：
● 第一种定义，也是最正宗的定义：
If for each object o1 of type S there is an object o2 of
type T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 is
substituted for o2 then S is a subtype of T.
如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。

● 第二种定义：
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
所有引用基类的地方必须能透明地使用其子类的对象。

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

里氏替换原则为良好的继承定义了一个规范：子类必须完全实现父类的方法

注意 
1. 在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。
   如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

2. 子类可以有自己的个性, 是指有子类出现的地方，父类未必就能适应。

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

4. 覆写或实现父类的方法时输出结果可以被缩小

　依赖倒置原则（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语言中的表现就是：
● 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
● 接口或抽象类不依赖于实现类。
● 实现类依赖接口或抽象类。

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

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

依赖的三种写法
1. 构造函数传递依赖对象
2. Setter方法传递依赖对象
3. 接口声明依赖对象，也叫接口注入

依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。

实现依赖倒置原则遵循以下的几个规则：
● 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。
● 变量的表面类型尽量是接口或者是抽象类。
● 任何类都不应该从具体类派生如果一个项目处于开发状态，但这也不是绝对的，只要不超过两层的继承都是可以忍受的。无法获得父类代码的情况下, 特别是负责项目维护的不考虑这个规则.
● 尽量不要覆写基类的方法: 如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。
● 结合里氏替换原则使用：接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，在适当的时候对父类进行细化。

　接口隔离原则(Interface Segregation Principle)

先看接口分为两种：
● 实例接口（Object Interface），在Java中声明一个类，然后用new关键字产生一个实例，这是一种接口。比如你定义Person这个类，然后使用Person zhangSan=new Person()产生了一个实例，这个实例要遵从的标准就是Person这个类，Person类就是zhangSan的接口。
● 类接口（Class Interface），Java中经常使用的interface关键字定义的接口。

两种定义：
● Clients should not be forced to depend upon interfaces that they don't use.（客户端不应该依赖它不需要的接口。）
● The dependency of one class to another one should depend on the smallest possible interface. （类间的依赖关系应该建立在最小的接口上。）

定义剖析:
第一种定义：“客户端不应该依赖它不需要的接口”，客户端需要什么接口就提供什么接口，把不需要的接口剔除掉，那就需要对接口进行细化，保
证其纯洁性.
第二种定义：“类间的依赖关系应该建立在最小的接口上”，它要求是最小的接口，也是要求接口细化，接口纯洁，与第一个定义如出一辙，只是一个事物的两种不同
描述。

因此我们可以把这两个定义概括为一句话：建立单一接口，不要建立臃肿庞大的接口。通俗一点讲：接口尽量细化，同时接口中的方法尽量少。

与单一职责原则的区别：
单一职责要求的是类和接口职责单一，是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。例如一个接口的职责可能包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束“不使用的方法不要访问”，按照单一职责原则是允许的，按照接口隔离原则是不允许的，因为它要求“尽量使用多个专门的接口”。专门的接口指什么？就是指提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。

接口隔离原则是对接口进行规范约束，其包含以下4层含义：
● 接口要尽量小：这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是有限度的，首先就是不能违反单一职责原则。
● 接口要高内聚
● 定制服务
● 接口设计小是有限度的，过于小的后果是结构的复杂化，开发难度增加，可维护性降低。

　迪米特法则（Law of Demeter，LoD）

迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least KnowledgePrinciple，LKP）

虽然名字不同，但描述的是同一个规则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系。

迪米特法则对类的低耦合提出了明确的要求，其包含以下4层含义。
1. 只和朋友交流： 一个方法尽量不引入一个类中不存在的对象，

1. 朋友间也是有距离的：在设计时需要反复衡量是否还可以再减少public方法和属性，是否可以修改为private、package-private（包类型，在类、方法、变量前不加访问权限，则默认为包类型）、protected等访问权限，是否可以加上final关键字等。迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。

2. 是自己的就是自己的：经常会出现这样一个方法：放在本类中也可以，放在其他类中也没有错，那怎么去衡量呢？你可以坚持这样一个原则：如果一个方法放在本类中，既不增加类间关
   系，也对本类不产生负面影响，那就放置在本类中。

3. 谨慎使用Serializable，注意服务器和客户端要一致。

　开闭原则(Open Closed Principle)

定义:
Software entities like classes,modules and functions should be open for extension but closed for modifications. 
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

开闭原则是一个非常虚的原则，前面5个原则是对开闭原则的具体解释，需要去体会和掌握。

总结

● Single Responsibility Principle：单一职责原则
● Open Closed Principle：开闭原则
● Liskov Substitution Principle：里氏替换原则
● Law of Demeter：迪米特法则
● Interface Segregation Principle：接口隔离原则
● Dependence Inversion Principle：依赖倒置原则

把这6个原则的首字母（里氏替换原则和迪米特法则的首字母重复，只取一个）联合起来就是SOLID（solid，稳定的），其代表的含义也就是把这6个原则结合使用的好处：建立
稳定、灵活、健壮的设计，而开闭原则又是重中之重，是最基础的原则，是其他5大原则的精神领袖。