设计模式之六大原则（一）

设计模式之六大原则（一）

单一职责原则（Single Responsibility Principle，简称SRP）

一句话概述

应该有且仅有一个原因引起类的变更

优缺点汇总

优点如下：

● 类的复杂性降低，实现什么职责都有清晰明确的定义；

● 可读性提高，复杂性降低，那当然可读性提高了；

● 可维护性提高，可读性提高，那当然更容易维护了；

● 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

缺点：最大的缺点就是会增加类的数量，所以单一职责的界定就尤为重要。

举例说明

用现实中比较通俗的例子说明一下。比如你有一个可爱的儿子，他上小学了，家里开始鸡飞狗跳了，于是我们规定你和媳妇的职责，爸爸只负责陪儿子玩，妈妈负责督促儿子的学习，坚决不能交叉。有一天爸爸加班回不来，儿子的玩受到了影响，可能需要他自己无聊的玩了，但是好处是学习没受影响，毕竟妈妈还在，该学的习一点没变，这就符合单一职责，爸爸和妈妈只负责一件事，一个变更不会影响另一个的进展。

但是现实中爸爸和妈妈不可能这么严格的分工，实际可能就是，爸爸加班了，儿子需要妈妈陪着玩，妈妈玩着玩着就到了睡觉的点了，于是学习就得泡汤了。

适用范围

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

说白了，就是单一职责的范围得凭业务、项目等经验来确定。

里氏替换原则（Liskov Substitution Principle，LSP）

一句话概述

所有引用基类的地方必须能透明地使用其子类的对象。

也就是子类的适用范围是广于父类的，详细包含四个维度的说明，具体见规则细说

优缺点汇总

优点如下：

● 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；

● 提高代码的重用性；

● 子类可以形似父类，但又异于父类，“龙生龙，凤生凤，老鼠生来会打洞”是说子拥有父的“种”，“世界上没有两片完全相同的叶子”是指明子与父的不同；

● 提高代码的可扩展性，实现父类的方法就可以“为所欲为”了，君不见很多开源框架的扩展接口都是通过继承父类来完成的；

● 提高产品或项目的开放性。

缺点如下：

● 继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法；

● 降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束；

● 增强了耦合性。当父类的常量、变量和方法被修改时，需要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的结果——大段的代码需要重构。

举例说明

小王开了一个书店，书的种类多种多样，有小说、工具书、儿童漫画等等。书就是父类，不同的书就是他的子类。所有书都有共同的特点，比如有作者、出版社、页数、目录、售价等等。但是他们又有自己的个性部分，比如小说最近大家都在网上看，不好卖，小王专门针对小说进行打折促销，这样就覆盖了父类获取价格的方法。在这种继承关系中，就用到了里氏替换原则。

规则细说

● 子类必须完全实现父类的方法

●子类可以有自己的个性

● 覆盖或实现父类的方法时输入参数可以被放大

● 覆写或实现父类的方法时输出结果可以被缩小

适用范围

里氏替换原则主要是为了代码的共用性，在继承共性的同时，有支持子类拥有一定的个性。但是一定要避免太个性化的子类的诞生，如果一个子类他的方法大多都是个性化的，那么就没必要继承父类，否则会让代码间的耦合关系变得混乱。

附言

本人最近在研究设计模式，准备总结分享出来，一是为了总结消化，二是为了分享，希望能对需要的人提供一定帮助。水平有限，如文章或代码中有不当之处欢迎指正。另外在将设计模式总结完毕后，会将代码工程（git）分享出来，以供大家调试运行使用。喜欢的欢迎三连支持一波，小弟在此感激不尽。

文章内容主要参考文献《设计模式之禅（第二版）》以及网络搜罗部分内容和实际工程运行所得。