我们都知道面向对象有三大特性：封装、继承、多态。所以我们在实际开发过程中，子类在继承父类后，根据多态的特性，可能是图一时方便，经常任意重写父类的方法，那么这种方式会大大增加代码出问题的几率。比如下面场景：类C实现了某项功能F1。现在需要对功能F1作修改扩展，将功能F1扩展为F，其中F由原有的功能F1和新功能F2组成。新功能F由类C的子类C1来完成，则子类C1在完成功能F的同时，有可能会导致类C的原

初学者在编程的时候可能一开始会有这样的经历，使用一个类来实现很多的功能，新添加的甚至不相关的功能都放在一个类里来实现，煮成了一锅大杂烩，往往使得某个类包罗万象，无所不能。可能刚开始实现功能比较简单，这样做不会引发什么特别大的问题。但是随着项目复杂度的提升，各种不相关的实现代码耦合在一起，一旦有功能的更改或增删，修改的代码很可能会导致其他功能的正常运行。这种编程方式显然是不可取的，也就是违背了所谓的

01 单一职责原则 一个类只负责单一功能 02 里氏替换原则 子类对象在任何场景下都能替换父类对象； 不要覆盖父类已经实现的方法 03 依赖倒转 高层模块不应该依赖低层模块的实现，二者都应该依赖抽象； 抽象不应该依赖细节，细节依赖抽象 04 接口隔离原则 接口应该最小粒度，不要让实现类实现无用的方法 05 迪米特法则 一个对象对其他对象应该保持最少的了解； 对象之间只与直接朋友通信： #

一、定义 规定一个类只有一个发生变化的原因。通俗理解为：一个类只负责一项职责。 友情提醒：xmind导出的图片有点模糊，请放大查看 二、 问题的由来 2.1 问题 类T负责两个不同的职责，当职责P1改变需求时需要修改T类,这时候就有可能因为修改的逻辑导致职责P2出现故障 2.2 解决方案 遵循单一原则，创建两个类T1和T2，在修改T1的时候不会影响T2，同理，修改T2的时候也不影响T1的逻辑 三、

一、定义 所有引用基类的地方，必须能透明的使用其子类对象。通俗的说：遵循里氏替换原则的代码，只要父类出现的地方就可以使用子类来替换它而不会产生任何错误，使用者不需要知道用的是父类还是子类。 它的核心是继承 友情提醒：xmind导出的图片有点模糊，请放大查看 二、优缺点 它的核心是继承，它的优缺点也是继承的优缺点 2.1 优点 代码共享：子类拥有父类的属性和方法 重用性：子类重用父类的代码 子父类异

一、定义 高层模块不应该依赖于底层模块，二者都应该依赖其抽象，抽象不应该依赖细节，细节应该依赖抽象。 抽象就是接口和抽象类；细节就是具体的实现类 依赖倒置本质：通过抽象即接口或者抽象类，使各个类和模块间彼此独立，实现模块间的松耦合 友情提醒：xmind导出的图片有点模糊，请放大查看 二、 问题的由来 2.1 问题 类A直接依赖类B，假如要将类A改为依赖类C，那么必须修改类A来完成。这种场景下，类A

转载：http://www.voidcn.com/article/p-obarfzju-bme.html 定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。 解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P

转载：http://www.voidcn.com/article/p-tawwljft-bme.html 肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。 定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。 解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类