这里我们要做的是了解个个原则的优缺点，而不是生搬硬套

单一职责原则(Single Responsibility principle)

A class should have only one reason to change.

一个类应该只有一种原因引起它的状态变化

嗯嗯， 你设计的类符合SRP原则么？

优点：类的复杂性降低，提高类的可读性，相应的变更引起的风险低

缺点：职责难以划分，若粒度划分不好，可能难以维护

SRP最难的就是职责的划分，有粒度过小，会导致类的大量增加；若粒度过大，那就会出现一个万能类，大公司早期项目估计都有这样的“牛”类，会导致后期难以维护和扩展。

PS：

1. SRP用在方法和接口上还是很不错的，一个方法和接口只做一件事情

2. 职责划分粒度掌握不好，也总比指责不清晰要好很多，否则一旦出现问题，所有类都抱怨说这不是我的责任

里氏替换原则(Liskov Substitution Principle)

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

程序P中一个类T的实例o2能够被另一个类S的实力o1替换而不引起程序结果改变，那么S是T的子类

如果USB是父类抽象接口，那么所有设备实现就是子类(2.0, 3.0, type-c)

优点：减少代码重复，提高代码可重用性与可扩展性

缺点：继承是入侵性的，子类无法甩掉父类的一些方法和属性。代码耦合增高灵活性降低，修改一处代码，不得不考虑是否会影响相关子类

PS:

1. LSP说的是用子类替换父类，反过来是不成的;

2. 若子类无法完成父类的某些方法或功能，那么子类无法替换父类而达到程序行为不变，违背了LSP;

3. 若遵守LSP，子类覆盖时应该调用父类方法或完成和父类相同的逻辑;

4. 若遵守LSP，需要保证每个接口的对应参数和返回值，同样遵守LSP；

5. 考虑到可维护性，继承不应该超过三层

依赖倒转原则(Dependence Inversion Principle)

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.

高层不应该依赖底层模块，两者应该抽象(无法被实例话的接口，类啥的)；抽象不应该依赖细节；细节应该反而依赖抽象，换句话说也就是面向接口编程.

优点：减少类之间的耦合，提高可读与可维护性，降低并行开发风险
缺点：目前没发现，除了依赖特别强的情话下无法使用

PS:

1. 底层模块是指不可分割的原子逻辑，应该符合SRP

2. 面向接口编程很容易实现TDD(Test-Driven Development，测试驱动开发)

3. 高层不依赖于底层，换句话说如果底层员工不干了，你还能依照抽象，在寻找其他能够胜任的人来接替。大大增加公司的稳定性

接口隔离原则(Interface Segregation Principle)

1. Clients should not be forced to depend upon interfaces that they don’t use.

2. The dependency of one class to another one should depend on the smallest possible interface.

1.客户端不应该依赖它不需要的接口
2.类间的依赖关系应该建立在最小的接口上

优点：结构清晰，减少不必要依赖，增加灵活性
缺点：与SRP一样接口粒度是个难以权衡的问题，若功能一样，粒度过小，会导致接口过多，结构复杂

PS:

1. 根据SRP接口粒度应该尽量小，即接口内部公开方法要尽量少，减少不必要的public接口

2. 接口要尽量高内聚，即接口内部能够尽量独立处理事物，减少对外部的依赖

3. 接口要可定制化，同样的功能对内部模块和对外部模块显然会有权限等限制要考虑，以防止误用

4. 一个接口尽量只服务一个字模块或业务逻辑

5. 若接口被污染，尽量去修改，若风险较大，可以采用适配器转化处理

迪米特法则(Law of Demeter) or 最少知识原则(Principle of Least Knowledge)

1.Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
2.Each unit should only talk to its friends; don’t talk to strangers.
3.Only talk to your immediate friends.

每个单元应对周围有最少的了解 and 只和朋友交流

优点：类之间依赖更少，更易于扩展和维护
缺点：为了减少依赖可能会增加更多的wrapper方法(中转，跳转)，也可能因此增加大量不必要的工作

PS：
朋友=成员变量 or 成员方法的输入输出参数

开闭原则(Open/closed principle)

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

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭

PS: 以上五个原则都是开闭原则的具体形态

23个设计模式

单例模式