一、单一职责原则（Single Responsibility Principle 简称SRP）
原定义：There should never be more than one reason for a class to change.
既是：应该有且只有一个原因引起类的变更.
单一职责的好处：
1、类的复杂性降低，实现什么职责都有清晰明确的定义；
2、可读性提高了，复杂性降低了，可读性自然也就提高了；
3、可维护性提高了，可读性提高了，那当然可读性就提高了；
4、变更引起的风险降低，变更是必不可少的，如果一个接口的单一职责做的好，一个接口的修改只对相应的实现类有影响，对其他接口无影响，这对系统的扩展性、维护性都有很大的帮助
二、里氏替换原则（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 where o1 is subsitituted 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 use objects of derived classes without knowing it(所有引用基类的地方都必须能够透明的使用其子类的对象)
通俗点讲：只要父类能够出现的地方子类都能够出现，而且替换为子类也不会产生任何异常或错误，使用者根本就不需要知道是父类还是子类。但是，反过来就不戏行了。子类出现的地方，父类就不一定能够适应。
里氏替换原则包含的4层含义：
1、子类必须完全实现父类的方法；
2、子类可以有自己的特性；
3、覆写或者实现父类的方法时输入的参数可以被放大；
4、覆写或者实现父类的方法时输出的结果可以被缩小；
三、依赖倒置原则（Dependence Inversion Principle DIP）
原定义：High level modules not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstactions.
既是：
1、高层模块不应该依赖底层模块，两者都应该依赖其抽象；
2、抽象不应该依赖细节；
3、细节应该依赖抽象；
该原则在java中的表现就是：
1、模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或者抽象类产生的；
2、接口或抽象类不依赖于实现类；
3、实现类依赖接口或抽象类；
更加精简的定义就是“面向接口编程“————OOD（Object-Oriented Design,面向对象设计）
依赖倒置原则的本质就是通过抽象（抽象类或者接口）使各个类或模块的实现彼此独立，不互相影响，实现模块见的松耦合，如果需要使用该规则，需要遵循以下几个规则：
1、每个类尽量都有接口或者抽象类，或者抽象类和接口两者都具备（这个是该原则的基本要求，接口和抽象类都是抽象，有了抽象才可能依赖倒置）；
2、变量的表面类型尽量是接口或者抽象类；
3、任何类都不应该从具体类派生；
4、尽量不要覆写基类的方法（如果基类是一个抽象类，并且该方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响）；
5、结合里氏替换法使用；
四、接口隔离原则
接口隔离原则的含义：
1、接口要尽量小（核心定义）；
2、接口要高内聚；
高内聚就是提高接口、类、模块的出来能力，减少对外的交互。
3、定制服务；
定制服务就是单独为一个个体提供优良的服务。
4、接口设计是有限度的；
五、迪米特法则（Law of Demeter LOD）也称最少知识原则(Least knowledge Principle LKP)
定义：一个对象应该对其他对象有最少的了解。
通俗的讲就是一个类应该对自己需要耦合或者调用的类知道的越少越好。
六、开闭原则
定义：Software entities like classes,modules and functions should be open for extension but closed for modifications
既是：一个软件实体如类，模块和函数应该对扩增开放，对修改关闭。（软件实体应该通过扩展（集成类，实现接口）来实现变化，而不是通过修改已有代码来实现改变）