一、开闭原则（OCP:Open-Closed Principle）
软件实体，如类，模块与函数，对于扩展应该是开放的，对于修改是关闭的。
由于客户的需求总是不断的变化和演进的，新需求进来时，要修改代码，尽量使用继承或组合的方式来扩展类的功能，不要直接修改类的代码。实现开闭原则的关键是对问题进行抽象化，将与具体实现分离，使用接口或抽象类对应用的可变性部分进行封装，通过扩展已有模块或系统，以满足新的需求。
二、里氏代换原则（LSP:Liskov Substitution Principle）
在代码里，子类能够替换它们的父类，且程序的功能不受任何影响，但反过来父类不一定能替换它的子类，因为子类中可能增加了自己特有的方法。尽量把父类设计为抽象类或者接口，由子类继承父类或实现父接口，运行时，可用子类实例替换父类实例，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。
三、单一职责原则（SRP:Single Responsibility Principle）
通俗的讲，一个类、接口应该只负责一项职责。如果一个类有多个职责，容易造成职责耦合，当一个职责发生变化时，可能会影响其它的职责。同时，多个职责耦合在一起会影响复用性。
四、依赖倒置原则(DIP:Dependence Inversion Principle)
高层模块不应该依赖于低层模块，它们应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
可以理解为抽象不应当依赖于细节；细节应当依赖于抽象；要针对接口编程，不针对实现编程。在编程过程中，尽量使用父类或上层接口作为传递参数，成员变量。
五、接口隔离原则（ISP:Interface Segregation Principle）
一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口，尽量使用多个专门独立的接口而不要使用单一臃肿的接口，过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干。
六、最少知识原则（LKP:Least Knowledge Principle）
"只与你最直接的朋友交流",可表述为尽量减少对象之间的交互，从而减小类之间的耦合。不要让一个类依赖于太多的其他类，尽量减小依赖关系，简言之，一定要做到：低耦合，高内聚。
七、组合/聚合复用原则（CARP:Composition/Aggregation Reuse Principle）
当要扩展类的功能时，优先考虑使用组合，而不是继承。记住，优先使用has-a,不是 is-a.