1. 单一职责原则（SRP: Single Resposibility Principle）
用“职责”或“变化原因”来衡量接口或类设计得是否优良，但“职责”和“变化原因”都是不可度量，因项目而异。
好处：
类的复杂性降低，职责有清晰明确的定义
可读性提高
可维护性提高
变更引起的风险降低
例如：属性、行为分开。
我单纯，所以我快乐。
最佳实践：接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。
2. 里氏替换原则（LSP: Liskov Subsititution Principle）
继承优点：代码共享，提高代码重用性，形似父类又异于父类，提高代码的可扩展性，提高项目或产品的开放性
继承缺点：侵入性，降低灵活性，增强耦合性
如何扬长避短？LSP为良好的继承定义了一种规范。
检验标准：只要父类能出现的地方，用子类替换后，不会产生任何异常和错误。说明符合LSP规范。
四层含义：
做系统设计时，经常会定义一个接口或抽象类，调用类直接传入接口或抽象类。
如果子类不能完整实现父类的方法，或者父类的某些方法在子类中已经发生”畸形“，则建议断开父子继承单位，采用依赖、聚集、组合等关系代替继承。
采用LSP目的：增强程序健壮性，版本升级保持非常好的兼容性。
3. 依赖倒置原则（DIP: Dependence Inversion Principle）
模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系通过接口或抽象类产生的
接口或抽象类不依赖于实现类
实现类依赖接口或抽象类
一句话：面向接口编程
采用DIP目的：
减少类间的耦合性：发生变更时可检验是否松耦合。
提供系统稳定性：稳定性较高的设计，在周围环境频繁变化的时候，依然可以做到”我自岿然不动“。
降低并行开发引起的风险：否则很难实现并行开发。两个类之间有依赖关系，只要制定出两者之间的接口或抽象类就可以独立开发了。项目之间的单元测试也可独立运行。TDD（Test-Driven Development,测试驱动开发）模式是LSP的最高级应用。JMock工具可以根据抽象虚拟一个对象，用于测试。TDD，先写好单元测试类，在写实现类，特别适合研发类项目或项目成员整理水平较低的情况下采用。
提高代码的可读性和可维护性。
依赖三种写法：
最佳实践：
每个类尽量都有接口或抽象类，或者抽象类或接口两者都具备
变量的表面类型尽量是接口或者抽象类
任何类都不应该从具体类派生
尽量不要覆写基类的方法
结合LSP原则使用
通俗的规则：接口负责定义public属性和方法，并且声明与其他对象的依赖关系；抽象类负责公共构造部分的实现；实现类准确实现业务逻辑，同时在适当时候对父类进行细化。
4. 接口隔离原则（Interface Segregation Principle）
定义：建立单一接口，不要建立臃肿庞大的接口。即接口尽量细化，同时接口中的方法尽量少。
与单一职责原则不同。一个从业务角度划分职责；一个是里面的方法不要太多，否则权限控制不便，即与调用者无关的方法都暴露出来了。
4层含义：
接口要尽量小：根据接口隔离原则拆分接口时，首先必须满足单一职责原则
接口要高内聚【高内聚：提高接口、类、模块的处理能力，减少对外交互】：@H_404_256@要求接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本。
接口设计是有限度的：@H_404_256@接口设计粒度越小，系统越灵活，结构越复杂，开发难度越大，可维护性越低。把握好”度“。
最佳实践：
5. 迪米特法则（LoD,Law of Demeter）/最少知识原则（LKP,Least Knowledge Principle）
一个对象应该对其他对象有最少的了解。一个类应该对自己需要耦合或调用的类知道得最少，被耦合或调用的类的内部是如何复杂都与我我关，我只知道你提供的public方法，其他我一概不关心。
类内高内聚，类间低耦合。
LoD法则要求尽量“内敛”，尽量不要对外公布太多的public方法和非静态public变量，多使用private,package-private,protected等访问权限。
方法放在本类可以，放在其他类中也没有错，如何衡量？原则：如果一个方法放在本类中，不增加类间关系，也对本类不产生负面影响，就放置在本类中。
6.开闭原则（Open Closed Principle）
定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
理解：一个软件实体应该通过扩展来实现变化，而不是通过修改已有代码来实现变化。
开闭原则是最基础的一个原则，前面的五个原则都是开闭原则的具体形态。前五个原则就是指导设计的工具和方法，开闭原则才是精神领袖。
如何使用：
原文链接：https://www.f2er.com/javaschema/285333.html