一、概念
1)开放封闭原则(OCR,OpenForExtension, ClosedFor Modification Principle)
类的改动是通过增加代码进行的，而不是修改源代码。（对扩展开放，对更改封闭。类模块应该是可扩展的，但是不可修改）
2)单一职责原则 (SR,Single Resposlillty Principle)。
一个类应该仅有一个引起它变化的原因。
变化的方向隐含着类的责任。
3)依赖倒置原则 (DIP,Dependence Inversion Principle)
高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定)。
抽象(稳定)不应该依赖于实现细节(变化) ，实现细节应该依赖于抽象(稳定)。
4)接口隔离原则 (ISP,Interface Segegation Principle）
不应该强迫客户的程序依赖他们不需要的接口方法。一个接口应该只提供一种对外功能， 不应该把所有操作都封装到一个接口中去。接口应该小而完备。
5)里氏替换原则(LSP, Luskov Substitution Princlple)
任何抽象类出现的地方都可以用他的实现（子）类进行替换。实际就是虚拟机制，语言级别实现面向对象功能。
6)优先使用组合而不是继承原则(CARP,Composite/Aggregate Reuse Principle)
如果使用继承，会导致父类的任何变换都可能影响到子类的行为
如果使用对象组合，就降低了这种依赖关系。
7)迪米特法则(LOD,Law of Demeter)
一个对象应当对其他对象尽可能少的了解，从而降低各个对象之间的耦合，提高系统的可维护性。
例如在一个程序中，各个模块之间相互调用时，通常会提供一个统一的接口来实现。
这样其他模块不需要了解另外一个模块的内部实现细节。
当一个模块内部的实现发生改变时，不会影响其他模块的使用。(黑盒原理)
二、案例
1、开闭原则
解耦合的技术
繁忙的业务员案例
一个业务员需要做付款、取款、转账等一系列相关操作，如果客户比较多，并比较急的话，这样可能会存在问题。
轻松的业务员案例（抽象层，实现层）
抽象出一个业务员的类，然后根据业务需求将业务员的类拆分成存款业务员、转账业务员、取款业务员，将各个功能模块细化，并且在以后公共能添加中，不需要修改已经写好的代码，只是在原有框架的基础上添加新的业务实现逻辑。这样的做法极大的释放了业务员的工作能力以及工作效率。
2、依赖倒置原则
传统的过程式设计倾向于使高层次的模块依赖于低层次的模块，抽象层依赖于具体的层次。
例如电脑可以采用不同厂商的硬盘、CPU、显卡等硬件。针对不同硬件抽象出不同的接口，厂商根据这些接口设计自己的产品。电脑相当于高层的业务逻辑，向协议层靠。具体的CPU、内存、硬盘等相当于具体的厂商生产的产品，也向协议层靠拢。
3、迪米特法则
（1）和陌生人说话
（2）不和陌生人说话
（3）与依赖倒置结合，某人和抽象陌生人说话，让某人和陌生人进行解耦合