封装变化
“找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。”
换句话说，如果每次新的需求一来，都会使某方面的代码发生变化，那么你就可以确定，这部分的代码需要被抽出来，和其他稳定的代码有所区分。
单一职责原则
“一个类应该只有一个引起变化的原因。”
类的每个责任都有改变的潜在区域。超过一个责任，意味着超过一个改变的区域。这个原则告诉我们，尽量让每个类保持单一责任。当一个模块或一个类被设计成只支持一组相关的功能时，我们说它具有高内聚；反之，当被设计成支持一组不相关的功能时，我们说它具有低内聚。内聚是一个比单一责任原则更普遍的概念，但两者其实关系是很密切的。遵守这个原则的类容易具有很高的凝聚力，而且比背负许多责任的低内聚类更容易维护。
单一职责原则可以看作是低耦合、高内聚在面向对象原则的引申，将职责定义为引起变化的原因，以提高内聚性，减少引起变化的原因。
开放-关闭原则
"类应该对扩展开放，对修改关闭。”
一个软件实体（如类、模块和函数）应该对扩展开放，对修改关闭。意思是在一个系统或者模块中，对于扩展是开放的，对于修改是关闭的。一个好的系统是在不修改源代码的情况下，可以扩展你的功能。这样的设计具有弹性，可以应对改变，可以接受新的功能来应对改变的需求。而实现开闭原则的关键就是抽象化。
里氏替换原则
"任何基类可以出现的地方，子类一定可以出现。"
这一思想表现为对继承机制的约束规范，只有子类能够替换其基类时，才能够保证系统在运行期内识别子类，这是保证继承复用的基础。所有引用基类（父类）的地方必须能透明地使用其子类的对象。即子类必须能够替换基类出现的地方，子类也能在基类的基础上新增行为。
接口隔离原则
"客户端不应该依赖那些它不需要的接口。"
一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需要知道与之相关的方法即可。
依赖倒置原则
"要依赖抽象，不要依赖具体类。”
不能让高层组件依赖低层组件，而且，不管高层或低层组件，“两者”都应该依赖于抽象。要针对接口编程，不针对实现编程。
合成/聚合复用原则
"尽量使用合成/聚合，而不是继承关系来达到软件复用的目的。”
使用组合建立系统具有很大的弹性，不仅可将算法族封装成类，更可以“在运行时动态地改变行为”，只要组合的行为对象符合正确的接口标准即可。
也就是说，在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对象通过向这些对象的委派达到复用已有功能的目的。
迪米特法则
"只和你的密友谈话。"
迪米特法则又称最少知识原则，它告诉我们要减少对象之间的交互，只留下几个“密友”。当你正在设计一个系统，不管是任何对象，你都要注意它所交互的类有哪些，并注意它和这些类是如何交互的。这个原则希望我们在设计中，不要让太多的类耦合在一起，免得修改系统中一部分，会影响到其他部分。如果许多类之间相互依赖，那么这个系统就会变成一个易碎的系统，它需要花许多成本维护，也会因为太复杂而不容易被其他人了解。
每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。也就是说，一个对象应当对其他对象有尽可能少的了解。一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你所提供的方法，我就调用这么多，其他的一概不关心。
好莱坞法则
“别调用我们，我们会调用你。”
好莱坞原则可以给我们一种防止“依赖腐败”的方法。当高层组件依赖低层组件，而低层组件又依赖高层组件，而高层组件又依赖边侧组件，而边侧组件又依赖低层组件时，依赖腐败就发生了。在这种情况下，没有人可以轻易地搞懂系统是如何设计的。在好莱坞原则下。我们允许低层组件将自己挂勾到系统上，但是高层组件会决定什么时候和怎样使用这些低层组件。换句话说，高层组件对待低层组件的方式是“别调用我们，我们会调用你”。