单一职责原则
一个类永远只有一个职责。
一套软件就像是一个团队，每个类就是团队中的一个成员。团队如果想稳定的发展。这些类就要各司其职，分工明确。如果类之间的功能出现了混淆，那么软件的 整体结构就会非常的混乱。就像管理学中的一句话，如果一个职责由每个员工负责，那么这个职责就没有员工在负责。 这个原则的概念非常简单，也是非常基础的。很多人尽管没有学习过面向对象的思想，但是经常写代码之后也会不自觉的遵守这个原则。
Ps： 在遵循单一职责原则的时候，常常会遇到职责扩散的问题。什么是职责扩散呢？这里简单说下，在日志生活中，我们在分类职责时，发现很多平常不受重视的职责， 但是这些职责又不能忽视。于是就依次累加，最后分起类来会无穷无尽（有兴趣的读者可以参考下长尾定理）。为了解决这种问题，我们就需要有一些类，他的职责 比较综合（类似于“其它”）。类似于一个帮助类。但是这个类又不能太复杂了，否则我们就应该考虑怎么把这个类分离开来。究竟这个类的复杂程度到了什么时候 情况下，我们就应该拆分呢？这个需要程序员根据软件自身的复杂情况来判断，没有一个统一的标准。

里氏替换原则
“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”
——“继承必须确保超类所拥有的性质在子类中仍然成立“
这个原则主要是为了体现面向对象的“继承”特征来提出的。 它的主旨就是，能够使用基类的地方，必然也能够透明的使用其子类，并且保证不会出错。为了保证这种透明的无差别的使用，子类在使用时不应该随意的重写父类 已经定义好的非抽象的方法。因为这些非抽象方法，类似于某种职能或契约，当父类保持这种约定时，子类也应该遵循并保证该特性，而非修改该特性。 我们在写代码的时候，如果一个参数设定的是基类（或接口、抽象类），那么我们传送子类进去，一样可以正常使用。因为基类相对于父类，只是一个更丰富，更具体，更详细的表现形式。而不应该出现，传入父类运行某种方法没有问题，可是传入子类运行时就报错了。这在日常生活中也可以理解，汽车作为父类，他下面有卡车、 轿车。轿车下边又有两厢，三厢等不同的继承。但是无论是哪种汽车（父类）的职能，对于他的子类（卡车或轿车）都应该具有相同的职能，而不是相反的职能。以 至于子类的子类（本例中是两厢轿车）也应该拥有汽车一致的功能。
我们在写代码中，很容易出现复写了父类的方法后，父类的方法发生了改动，而未考虑到子类的方法也需要作出相应的改动，导致代码出现错误。 通俗一点，可以理解为子类是遗传自父类的。他在各种职能上也应该一脉相承自父类。而不应该随意改变。

依赖置换原则
这个原则的名字比较唬人，我们先看看他的内容究竟是什么。在设计模式中对该原则有两句经典的描述：
（1）高层模块不应该依赖底层模块。两者都应该依赖抽象。
（2）抽象不应该依赖细节，细节应该依赖抽象。
这两句话的含义是：高层模块不应该依赖底层模块。两者应该通过抽象的东西进行关系链接（抽象的东西是指接口或者抽象类）。其次抽象类或者一个接口不应该依赖某个实现类。而这些实现类反而应该依赖于这个抽象类的设定。
通俗一点的说法就是，模块之间不应该直接产生调用关系（这是旧有的调用关系），两者应该通过面向接口（或者理解为面向设定的契约）进行编程。而这些契约和接 口更不应该以来自底层模块而设定。这些底层模块反而应该遵守这些契约。因为契约（抽象类、接口）相对于哪些实现代码，更不会改变，也就是更稳定。所以依赖 置换原则又叫作面向接口编程或面向契约编程。本意就是调整原来的依赖关系，重行进行了设定。

开闭原则
开闭原则是指：一个软件、一套系统在开发完成后，当有增加或修改需求时，应该对拓展代码打开，对修改原有代码关闭。
类一旦确定，就不应该再对其功能发生修改。这 是面向对象设计中，最重要最核心的原则。方案发布后，我们最担心的是什么？就是需求的变化，而需求一旦有变化，就要修改代码。大部分的bug往往就是这时 候引入的。因为修改代码时，我们往往将重点放在，如何解决当前bug上，反而没有注意因为这个修改，对原有设计的影响。
这条原则没有具体的指导要求，是前边五条原则的根本。

ps： 这六个面向对象的原则，并不是是和否的问题，也不是遵守和不遵守的问题。而是遵守的多和遵守的少的问题。我在文中也多次强调，我们在设计时，应该注意把握 一个度。诚然尽可能的遵守这些原则，会使代码维护起来更容易。但是维护粒度过细，所需要的设计和开发成本成倍增加，这显然是舍本逐末的。如图，面向对象开 发原则可以从以下这个坐标图展示，不论是哪个维度，他的值都不应该过满，甚至溢出，当然也不能很低，保持一个适当的度即可。