1、单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。如果这个类承担的职责过多，就等于关于把这些职责耦合在一起，一个职责的变化可能会消弱或则抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。软件设计要做的许多内容就是发现职责并把那些职责相互分离。判断是否应该分离出类来的准则是：如果能够想到多余一个动机去改变一个类，那么这个类就具有多余一个职责，这个类就应该分离。
2、开放-封闭原则：即开-闭原则。指软件实体（类、模块、函数等）应该可以扩展（开放），但是不可以修改（封闭）。但是在实际开发中做到完全的封闭是不可能的。因此设计人员就必须对他设计的模块应该对哪种封闭做出选择。他必须先猜测出最可能发生的种类变化，然后构造抽象来隔离那些变化。一旦变化发生时，就立即采取行动。面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。开发人员应该对程序中出现频繁变化的那部分做出抽象。
3、里氏代换原则：一个软件实体如果使用的是一个父类的话，那么一定适用于子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里，父类都可以替换成它的子类，而程序的行为没有变化。
4、依赖倒转原则：即抽象不应该一来细节，细节不应该一来于抽象。具体表现为：（1）、高层模块不应该一来低层模块，两个都应该一来抽象。（2）、抽象不应该一来细节，细节应该依赖抽象。 编程应该针对接口编程，而不是针对现实编程。这里的反转其实和上面说的里氏代换原则有关，只有当子类对象可以替换掉父类对象，软件单位的功能不受到影响时，父类才能正在被复用，而子类也能够在父类的继承上增加新的行为。程序中所有的依赖关系都应该终止于抽象类或者接口，那就是面向对象。反之，则是面向过程。
5、迪米特法则：页脚最少知识原则。即如果两个类不必彼此直接通信，那门两个类就不应当发生直接的相互作用。如果其中一个类需要直接调用另一个类的某一个方法的话，可以通过第三者转发这个调用。（这个法则强调了类之间的松耦合。类之间的耦合越弱，则越有利于复用。一个处在弱耦合的类被修改，不会对有关系的类造成波及。）