1.单一职责原则(SRP)
单一职责原则是实现高内聚、低耦合的指导方针
1)单一职责原则的好处：
类的复杂性降低，实现什么职责都有清晰明确的定义；
可读性提高，复杂性降低，可维性提高；
变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他接口无影响，对系统的扩展性、维护性有较大的帮助。
2)常见错误提醒：
持久化与业务规则的耦合。
Employee类包含了业务规则和对持久化的控制。业务规则经常变化，而持久化方法却一般不变，而且变化原因也完全不同。将这两个职责耦合在一起，将导致每次因为业务规则变化调整Employee类时，所有持久化部分的代码也要跟着变化。
3）例子
一个应用可能希望使用Retangle类计算矩形的面积，但是却被迫将绘制矩形相关的代码也包含进来 一些逻辑上毫无关联的原因可能导致应用失败如果GraphicalApplication的需求发生了变化，导致Rectangle的改变，这样的变化会要求我们重新构建、测试以及部署ComputationalGeometryApplication，否则其将莫名其妙的失败。
将两个职责分离到两个完全不同的类中，修改后
2.开-闭原则(OCP)
软件实体（类、模块、函数等）应该是可以扩展的，同时还可以是不必修改 的，更确切的说，函数实体应该：
对扩展是开放的
当应用的需求变化时，我们可以对模块进行扩展，使其具有满足改变的新的 行为。即：我们可以改变模块的功能
对更改是封闭的
对模块进行扩展时，不必改动模块已有的源代码或二进制代码。
对可变性的封装原则：
找到一个系统的可变因素，将之封装起来。
考虑你的设计中什么会发生变化
对应思路：什么会导致设计改变具体的：
一种可变性不应该散落在代码的很多角落里，而应被封装在一个对象里。 (继承可看作封装变化的方法。 )
一种可变性不应与另一种可变性混在一起。 (继承层次不应太多。 )
3. LisKov替换原则(LSP)
一个软件实体如果使用的是一个基类的话，一定适用于其子类，而且根本不能觉察出基类对象和子类对象的区别。
例子：长方形不能继承正方形，这样父类不能替换子类，应该再继承一个四方形的接口类
4. 依赖倒臵原则(DIP)
“高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。”
“要针对接口编程，不要针对实现编程。”
例子
上述设计使得Button可以控制所有愿意实现ButtonServer接口的设备，甚至是一个尚未开发出来的设备。
5.接口隔离原则(ISP)
“使用多个专门的接口比使用单一的总接口要好”
“一个类对另外一个类的依赖性应建立在最小的接口上不应该强迫客户依赖于他们不用的方法。一个类的不内聚的“胖接口”应该被分解成多组方法，每一组方法都服务于一组不同的客户程序。
例子
6、组合/聚合复用原则(CARP)
“要尽量使用组合/聚合，尽量不要使用继承。
要正确的选择组合/复用和继承，必须透彻地理解里氏替换原则和Coad法则。
只有当以下Coad条件全部被满足时，才应当使用继承关系：
- 子类是超类的一个特殊种类，而不是超类的一个角色。区分“ Has-A‖和“ Is-A‖。 只有“ Is-A‖关系才符合继承关系“ Has-A‖关系应当用聚合来描述。
- 永远不会出现需要将子类换成另外一个类的子类的情况。如果不能肯定将来 是否会变成另外一个子类的话，就不要使用继承。
- 子类具有扩展超类的责任，而不是具有臵换掉（ override）或注销掉 （ Nullify）超类的责任。如果一个子类需要大量的臵换掉超类的行为，那 么这个类就不应该是这个超类的子类。
- 只有在分类学角度上有意义时，才可以使用继承。不要从工具类继承。
7、迪米特法则(LoD)
一个对象应该对其他对象有尽可能少的了解
1）狭义的迪米特法则(LoD)：
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。
如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
2）狭义的迪米特法则(LoD)的缺点：
遵循类之间的迪米特法则会使一个系统的局部设计简化，因为每个局部都不会与远距离的对象有直接的关联；但也会造成不同模块之间的通信效率降低，会使系统的不同模块之间不容易协调。
在系统中造出大量的小方法，散落在系统的各个角落。这些方法仅传递间接的调用，与系统的商务逻辑无关。
当设计师试图从一张类图中看出总体的架构时，这些小方法会造成迷惑和困扰。
3）改进办法：与依赖倒置原则互补使用
引入一个抽象的类型引用“抽象陌生人”对象，使“某人”依赖于“抽象陌生人”，亦即将“抽象陌生人”变成“朋友”。
只要新的具体的“陌生人”具有相同的抽象类型，那么某人就无法区分它们，从而允许“陌生人”的具体实现可独立于“某人”而变化。
** 4）广义的迪米特法则(LoD)：**
对对象之间的信息流量、流向以及信息的影响进行控制。
充分体现封装的概念。
类的划分上，创建弱耦合的类；
类的结构设计上，每个类应降低成员的访问权限；
类的设计上，只要有可能，设计成不变类；
对其他类的引用上，对其他对象的引用应该降到最低。
