单一职责原则
一个合理的类，应该仅有一个引起它变化的原因，即单一职责，就是设计的这个类功能应该只有一个;
优点：消除耦合，减小因需求变化引起代码僵化。
开-闭原则
设计要对扩展有好的支持，而对修改要严格限制。即对扩展开放，对修改封闭。
优点：降低了程序各部分之间的耦合性，其适应性、灵活性、稳定性都比较好。当已有软件系统需要增加新的功能时，不需要对作为系统基础的抽象层进行修改，只需要在原有基础上附加新的模块就能实现所需要添加的功能。增加的新模块对原有的模块完全没有影响或影响很小，这样就无须为原有模块进行重新测试。
里氏代换原则
很严格的原则，规则是“子类必须能够替换基类，否则不应当设计为其子类。”也就是说，一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。
优点：可以很容易的实现同一父类下各个子类的互换，而客户端可以毫不察觉。
依赖倒换原则
“设计要依赖于抽象而不是具体化”。换句话说就是设计的时候我们要用抽象来思考，而不是一上来就开始划分我需要哪些哪些类，因为这些是具体。
“High level modules should not depend upon low level modules, both should depend upon abstractions. Abstractions should not depend upon details, details should depend upon abstractions.”
高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
另一种表述为： 要针对接口编程，不要针对实现编程。即“Program to an interface, not an implementation.”
优点：人的思维本身实际上就是很抽象的，我们分析问题的时候不是一下子就考虑到细节，而是很抽象的将整个问题都构思出来，所以面向抽象设计是符合人的思维的。另外这个原则会很好的支持（开闭原则）OCP，面向抽象的设计使我们能够不必太多依赖于实现，这样扩展就成为了可能，这个原则也是另一篇文章《Design by Contract》的基石。
接口隔离原则
“将大的接口打散成多个小接口”，让系统解耦，从而容易重构，更改和重新部署。
优点：会使一个软件系统功能扩展时，修改的压力不会传到别的对象那里。
迪米特法则或最少知识原则
这个原则首次在Demeter系统中得到正式运用，所以定义为迪米特法则。它讲的是“一个对象应当尽可能少的去了解其他对象”。
优点：消除耦合。