用最少的语言记住更多的东西
本文提纲
设计模式的目的
高内聚，低耦合
- 可重用性
- 可扩展性
- 可阅读性
- 可靠性
1. 单一职责原则(SRP)
单一职责原则提出了一个编写程序的标准，用”职责“或”变化原因“来衡量接口或类设计得是否优良。
Single Responsibility Principle
一个类(方法)只描述一件事, 应该有且仅有一个原因引起的变更。
There should never be more than one reason for a class to change（一个类的变化不应该有一个以上的原因引起）
单一职责原则好处
- 类的复杂性降低，实现什么职责都有清晰明确的定义
- 可读性提高，复杂性降低，那当然可读性提高了。
- 可维护性提高，可读性提高，那当然更容易维护了。
- 变更引起的风险降低。变更是必不可少的，如果接口单一职责做得好，一个接口修改只对相应的实现类有影响，对其它接口无影响，这对系统的扩展性，维护性都有非常大的帮助。
2. 开闭原则(OCP)
Open Closed Principle
3W原则： What 是什么，Why为什么，How怎么做。
对修改关闭，对扩展开放
3. 接口隔离原则(ISP)
Interface Segregation Principle
定义单一接口，不要建立臃肿庞大的接口。
- 客户端不应该依赖它不需要的接口
- 类间的依赖关系应该建立在最小接口上
接口隔离原则拆分接口时，首先必须满足单一职责原则
- 接口要高内聚
- 少使用public方法，接口对外承诺越少，对系统开发越有利，变更的风险也就越少，同时也有利于降低成本。
- 定制服务
- 就是单独为一个个体提供优良的服务。
- 只提供访问者需要的方法。
- 接口设计 是有限度的
- 接口的设计粒度越小，系统越灵活
- 一个接口只服务于一个子模块或业务逻辑。
接口隔离原则与单一职责原则的区别
接口隔离原则要求接口中的方法尽量少，专门的接口。
单一职责原则注重的是职责，是业务逻辑上的划分。
4. 里氏替换原则(LSP)
Liskov Substitution Principle
基类出现的地方子类也可以出现; 反过来就不行，有子类出现的地方，父类未必就能适应。
- 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类方法。
- 继承实际上就增加了耦合性，给程序带来侵入性。在适当情况下，尽量使用聚合，组合，依赖来解决问题。
- 父类中凡是已经实现好的方法，实际上是在设定规范和契约
5. 依赖倒置原则(DIP)
Dependence Inversion Principle
面向接口编程(OOD)，而不是面向实现编程。
- 高层模块不应该依赖低层模块，两者都应该依赖其抽象
- 抽象不应该依赖细节
- 细节应该依赖抽象
低层模块：每一个逻辑的实现都是由原子逻辑组成的， 不可分割的原子逻辑就是低层模块。
高层模块：原子逻辑的再组装就是高层模块
抽象：就是接口或抽象类，两种都是不能直接被实例化的
细节：就是实现类，实现接口或抽象类而产生的类就是细节，其特点就是可以直接被实例化。
抽象是对实现的约束，对依赖者而言，也是一种契约，不仅仅约束自己，同时也约束与外部的关系。其目的是保证所有细节不脱离契约的范畴。
依赖的三种写法：
依赖是可以传递的。只要做到抽象依赖，即使是多层的依赖传递也无所畏惧。
- 构造函数传递依赖对象
- Setter 方法传递依赖对象
- 接口声明依赖对象
什么是倒置
先说”正置“就是类依赖实现类的依赖，倒置即依赖抽象类，而不是依赖实现类。
*注：*依赖倒置原则是实现开闭原则的重要途径。依赖倒置原则没有实现，就别想实现对扩展开放，对修改关闭。在项目中，牢记”面向接口编程“就基本上抓住了依赖倒置的核心。
6. 迪米特原则(LKP)
也称最少知道原则 Least Knowledge Principle
不跟陌生人说话，即不能跨层访问
核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。
- 是自己的就是自己的
- 如果一个方法放在本类中，即不增加类间关系，也对本类不产生负面影响，那就放置在本类中。
- 类间解耦，但解耦是有限度的。过犹不及。
7. 合成复用原则
尽量多使用组合聚合接口，而不是继承关系