设计模式 - 设计原则
1. 单一职责原则
Single Responsibility Principle,简称SRP.
这个设计原则备受争议， 只要你想和别人争执、 怄气或者是吵架， 这原则是屡试不爽的。 如果你是老大，看到一个接口或类是这样或那样设的，你就问一句： “你设计的类符合SRP原则吗？ ”保准对方立马“萎缩”掉， 而且还一脸崇拜地看着你， 心想： “老大确实英明”。
单一职责原则的定义是： 应该有且仅有一个原因引起类的变更。
单一职责原则在实际中很难做到,我们只能尽量满足.
接口一定要做到单一职责， 类的设计尽量做到只有一个原因引起变化。
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 useobjects of derived classes without knowing it.（所有引用基类的地方必须能透明地使用其子类的对象。 ）
通俗点理解就是:
只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。 但是， 反过来就不行了， 有子类出现的地方， 父类未必就能适应。
3. 依赖倒置原则
Dependence Inversion Principle,简称 DIP
High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions hould not depend upon details.Details should depend upon abstractions.
翻译过来， 包含三层含义：
- 高层模块不应该依赖低层模块， 两者都应该依赖其抽象；
- 抽象不应该依赖细节；
- 细节应该依赖抽象。
一句话 面向接口编程
用张图来表示就是:要尽量避免左边的情况,而使用右边的.
依赖倒置原则.png
依赖的方式:
- 通过构造传递并保存到成员变量
- 使用setter 方法并保存到成员变量
- 在使用的方法中的传递参数中
依赖倒置原则在小项目中得不到很好的体现,而在大项目则是很好的利器!
4. 接口隔离原则
- 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.（类间的依赖关系应该建立在最小的接口上。）
简单来说就是:
建立单一接口， 不要建立臃肿庞大的接口
它跟单一职责原则容易混淆,到底是单一职责原则还是接口隔离原则,区别是他们站的角度不同:
- 单一职责原则:类和接口职责单一,注重的是 职责
- 接口隔离原则:接口的方法尽量少
我们要做是:
根据接口隔离原则拆分接口时， 首先必须满足单一职责原则。
5. 迪米特法则
迪米特法则（Law of Demeter， LoD） 也称为最少知识原则（Least Knowledge Principle， LKP）
定义:一个对象应该对其他对象有最少的了解
理解:
- 对一个类,暴露的public方法越少越好
- 只和朋友交流 (朋友指:成为变量或方法参数,除此之外都不是朋友)(也就是方法中不需要知道其他类了)
暴露的public方法越少越好.png
只和朋友交流.png
6. 开闭原则
这是六个原则中最重要的一个设计原则!如果把其他五个原则比喻为是西安类的话,这个原则就是他们的抽象类!
前五个原则就是指导设计的工具和方法， 而开闭原则才是其精神领袖。
Software entities like classes,modules and functions should be open for extension but closed for modifications.（一个软件实体如类、 模块和函数应该对扩展开放， 对修改关闭。 ）
实现开闭原则的方式有很多,比较普遍的是通过扩展一个类的方式(extends),这样可以复写原有的方法又不会对原有的类造成影响!
为什么要开闭原则?
- 通过扩展来添加功能,原有的测试类不需要改变,只需要添加新的测试类
- 粒度越小， 被复用的可能性就越大.缩小逻辑粒度， 直到一个逻辑不可再拆分为止。
- 读懂原有的代码已经很困难了,在原有的基础上在进行修改更不可能了!
- 需要在设计之初考虑到所有可能变化的因素
如何实现开闭原则?
- 使用抽象:抽象是对变化的封装,也是对代码的约束.通过抽象类或接口规划功能,在实现类中尽量不能出现public方法.抽象尽量稳定,不能随意添加或修改.
- 元数据控制模块i行为:元数据可以理解为配置参数,在spring中通过配置xml可以进行IOC的控制,从而不需要修改java代码.
- 制定项目章程:执行约束,开发人员都遵循.
- 封装变化:将变化封装到接口或抽象类中,使用23中设计模式来封装变化.
设计原则只是些原则,我们只能尽量遵循,实现过程中还要具体问题具体分析,一句话「尽量遵循设计原则」
