《设计模式之禅》读书笔记

六大设计原则

一.单一职责原则 Single Responsibility Principle (简称SRP)
定义：有且仅有一个原因引起类的变更。通俗的讲，一个类只负责一件事。
好处：
1.类的复杂性降低了，实现什么职责都有清晰明确的定义；
2.可读性提高；
3.可维护性提高；
4.引起的风险降低，变更是必不可少的，如果接口的单一职责做的
好，一个接口修改只对相应的实现类有影响，对其他接口无影响 ，这对系统的扩展性，维护性都有非常大的帮助。
使用：
单一职责适用于接口，类，同时也适用于方法。一个方法尽可能的做一件事情，比如一个方法修改用户密码，不要把这个方法放到“修改用户信息”方法中。
总结：对于单一职责原则，作者的建议是接口一定要做到单一职责，类的设计尽做 到只有一个原因引起变化。

二.里氏替换原则 Liskov Substitution Principle,LSP
定义：所有引用基类的地方必须能透明的使用其子类的对象。通俗讲：只要有父类本就不需要知道父类还是子类。但是反过来就不行，有子类的地方法父类未 必就能适应。
目的：
增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑。
知识点：
在类中调用其他类时务必要使用父类或者接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP。
如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖，聚集，组合等关系代替继承。
覆盖或实现父类的方法时输入参数可以被放大。
覆盖或实现父类的方法时输出结果可以被缩小。
总结：
在项目中，采用里氏替换原则时，尽量避免子类的“个性”，这个子类和父类之间的关系就很难调和了，把子类当作父类使用，子类的“个性”被抹杀；把子类单独作为一个业务来使用，则会让代码间的耦合关系变得扑塑迷离——缺乏类替代标准。
三.依赖倒置原则 Dependence Inversion Principle,DIP
定义：依赖倒置原则包含三层含义：
1.高层模块不应该依赖低层模块，两者都应该依赖其抽象；
2.抽象不应该依赖其细节；
3.细节依赖抽象
在java中的表现是：
1.模块间的依赖通过抽象类发生，实现类之间不发生直接依赖关系，其依赖关系通过接口或者抽象类产生的；
2.接口或者抽象类不依赖于实现类；
3实现类依赖接口或者抽象类。
简而言之就是：面向接口编程。
优点：减少类之间的耦合性，提高系统的稳定性，降低并行开发的风险，提高代码的可读性和可维护性。
最佳实践：
1.每个类尽量都有接口或抽象类，或者两者都具备；
2.变量的表面类型尽量是接口或者抽象类；
3.任何类都不应该从具体类派生；
4.尽量不要写覆盖基类的方法；
5.结合里氏代换原则使用

四.接口隔离原则
定义:
1.客户端不应该依赖它不需要的接口；
2.类间的依赖关系应该建立在最小的接口上。
通俗的讲：接口尽量细化，同时接口中的方法尽量少。
最佳实践：
1.一个接口只服务于一个子模块或业务逻辑；
2.通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到”满身筋骨“，而不是”肥嘟嘟“的一大堆方法；
3.已经被污染的接口，尽量去修改，若变化的风险较大，则采用适配器模式进行转化处理；
4.了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做你就照抄。
五.迪米特法则（Law of Demeter LoD）
定义：也叫最少知识原则（Least Knowledge Principle,LKP）,一个对象应该对其他对象有最少的了解。通俗的讲，一个类应该对自己需要耦合或者调用的类知道最少。
含义：
1.只和朋友交流
每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，例如：组合，聚合，依赖等 。
朋友类：出现在成员变量，方法的输入输出参数中的类称为朋友类，而出现在方法体内部的类不属于朋友类。
2.朋友之间也是又距离的
尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private,protected,package-private等访问权限。
3.是自己的就是自己的
如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放在本类中。
4.谨慎使用Serializable。
六.开闭原则
定义：软件实体（类,模块和函数）应该对拓展开放，对修改关闭。
1.通过接口或者抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；
2.参数类型，引用对象尽量使用接口或者抽象类，而不是实现类；
3.抽象类尽量保持稳定，一旦确定即不允许修改。