1. SRP（Single Responsibility Principle 单一原则）
单一职责很容易理解，所谓单一职责，就是一个设计元素只做一件事。
SRP 原则的核心含义是只能让一个类有且只有一个职责，永远不要让一个类存在多个改变的理由。换句话说，如果一个类需要改变，改变它的理由永远只有一个，如果存在多个改变它的理由，就需要重新设计该类，如果一个类承担的职责过多，那么就等于把这些职业耦合在一起了，一个职责的变化可能会抑制该类完成其他职责的能力，这样的耦合会导致脆弱的设计，当变化发生时，设计会受到意想不到的破坏。
2. OCP （Open Close Principle 开闭原则）
一句话：“Closed for Modification; Open for Extension”——“对变更关闭；对扩展开放”。
OCP是指在进行面向对象设计中，设计类或其他程序单位时，应该遵循对扩展开放对修改关闭的原则，开闭原则是判断面向对象设计是否正确的最基础的原理之一，开闭原则要求对扩展开放，扩展提供新的或改变原有的功能，让软件具有灵活性，开闭原则要求扩展功能不修改原有的代码，使软件在变化中保持稳定，遵循开闭原则的系统设计，可以让软件系统可复用，并且易于维护。
3. LSP（Liskov Substitution Principle 里氏替换原则）
子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract) 的概念推出。我们以学生为例，夜校生为学生的子类，因此在任何学生可以出现的地方，夜校生均可出现。这个例子有些牵强，一个能够反映这个原则的例子时圆和椭圆，圆是椭圆的一个特殊子类。因此任何出现椭圆的地方，圆均可以出现。但反过来就可能行不通。运用替换原则时，我们尽量把类B设计为抽象类或者接口，让C类继承类B(接口B)并实现操作A和操作B，运行时，类C实例替换B，这样我们即可进行新类的扩展(继承类B或接口B)，同时无须对类A进行修改。
里氏替换原则即如果一个软件实体使用的是基类，那么也一定适用于子类，但反过来的替换不成立。
如果有两个具体的类A和B之间的关系违反了里氏替换原则，那么在以下两种重构方案中选择一种：
1）创建一个新的抽象类C，作为两个具体类的超类，将A和B共同的行为移到C中，从而解决A和B行为不完全一致的问题
2）从B到A的继承关系改写为委派关系，子类型必须能替换掉他们的基本类型
4.DIP（Dependence Inversion Principle 依赖倒置原则）
依赖倒置（Dependence Inversion Principle）原则讲的是：要依赖于抽象，不要依赖于具体。简单的说，依赖倒置原则要求客户端依赖于抽象耦合。原则表述：抽象不应当依赖于细节；细节应当依赖于抽象；要针对接口编程，不针对实现编程。
依赖倒置原则，要以来于抽象，不要依赖于具体，也就是说要针对接口编程，不要针对实现编程，针对接口编程意味着应当使用接口和抽象类进行变量的类型声明，参量的类型声明，数据类型的转换等，任何变量都不应该覆盖它的任何基类中的已经实现的方法
5.ISP（Interface Segregation Principle 接口分隔原则）
采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。
接口隔离原则的含义是使用多个专门的接口比使用单一的接口要好，从客户端只需要某一些方法的话，那么就应当向客户端提供这些需要的方法，而不要提供不需要的方法提供接口意味着向客户端作出承诺，过多的承诺会给系统的维护造成不必要的负担，不应该强迫客户依赖于他们不用的方法接口属于客户，不属于他所在的类层次结构，多个面向特定用户的接口胜于一个通用接口。
