单一原则
单一原则：就一个类而言，应该仅有一个引起它变化的原（ASD）。
如果一个类承担的职责过多，就等于把这些职责耦合到了一起，一个职责的变化都可能会小柔或者一直这个类的完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。
所以在软件设计中真正要做的许多内容，就是发现职责并把这些职责相互分离。其实要判断是否应该分离出类来，也不难，那就是如果你能够想到多于一个冬季去改变一个类，那么这类就具有多于一个的职责，就应该考虑类的职责分离了。
开放闭合原则
开放闭合：指的是软件实体（类、模块、函数等等）对扩展开放，对修改闭合。
在实际开发中，我们做任何软件都不要指望系统一开始时需求认定，就再也不发生变化，这是不现实也是不科学的想法，而既然需求是一定变化的，那么我们在设计软件时就要做到相对容易修改，不至于在新需求一来，就要把整个程序推倒重来。
但是，绝对的对修改封闭是不可能的。无论模块是多么的封闭，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。当然去猜测一个程序发生的变化可能会比较难，这需要我们有丰富的经验才能做到。另一个途径是当小的变化发生时，就及早的去想办法应对发生更大变化的可能性，这个使我们相对比较容易做到的，对应到我们的实际开发中就是当一个点发生修改时，我们就要根据自己的公司业务特点判断出这点是否可能再次发生类似的变化，从而运用一定的设计模式来应对未来可能的变化。
我们需要注意的是，越早查明可能发生的变化，我们创建正确的抽象就会越简单，反之，就越困难。
总之，开放-闭合原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中蹭线出频繁变化的那些部分做出抽象，然后，对于应用程序中的每个部分都可以的进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样的重要。
依赖倒转（依赖倒置）原则
依赖倒置：抽象不应依赖细节，细节应该依赖于抽象。换句话说就是要针对接口编程，不要对实现编程。
特点：
1.高层模块不应该依赖底层模块。两个都应该依赖抽象
2.抽象不应依赖细节，细节应该依赖抽象
如何理解倒置呢？
在面向过程开发时，为了程序的复用，我们经常把常用的代码写成许许多多函数的程序库，这样我们在做新项目时，去调用这些底层的函数就可以了。比如我们做的项目大多要访问数据库，所以我们把访问数据库的代码写成函数，每次做新项目时就去调用这些函数。这也就叫做高层模块依赖底层模块。
高层依赖底层的缺点就在于，这种依赖其实是增加了高层模块和底层模块的耦合，如果有需求要我们修改底层模块的内容，就会导致高层模块的内容不可复用，这显然是不合理的。如果不管是高层模块还是底层模块，它们都只依赖于抽象，具体一点就是接口或者抽象类，只要接口是稳定的，那么任何一个更改都不用担心其他收到影响，这就使得无论是高层模块还是底层模块都可以很容易的被复用。
那为什么依赖了抽象的接口或者抽象类，就不怕更改呢？这里我们就要提到另一个原则：里氏替换原则。里氏替换原则本身是个非常复杂的数学定义，大概意思是一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化，这里可以简单的理解为子类型必须能够替换掉他们的父类型。也正是因为有了这个原则，是的继承复用成为了可能，只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。可以说，正是因为有了里氏替换原则，才使得开放-闭合原则成为可能，正是由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。
依赖倒置其实可以说是面向对象设计的标志，用哪种预言其实都不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象设计，反之那就是过程化的设计了。