注：本文来自Nemo, http://nemotec.github.io
单一职责原则(SRP)
一、全称
"Single Responsibility Principle" 单一职责原则
二、说明
There should never be more than one reason for a class to change.
应该有且仅有一个原因引起类的变更。一个类中应该是一组相关性很高的函数、数据的封装。
对于一个模块、一个类、一个方法等大小不一的单位，尽量做到简单明了、功能单一，这些单位按单一职责原则编写，代码简洁明了、通俗易懂。
单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则。因为单一职责原则没有明确的定义，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。
三、实现
1. 一个类只负责一项职责
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或者一直这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。而软件设计真正要做的许多内容，就是发现职责，并把这些职责相互分离。
实际需求发生变化时就应该应用SRP原则来重构代码，因为新的变化可能产生
要在职责扩散到我们无法控制的程度之前，立刻对代码进行重构。
2. 一个函数只完成一项功能
Java函数不应超过15行。当然这不是必须遵守的规范，意思是要我们写尽量短小简洁的函数，同时方法名最好能自解，这样做既不容易出错，也便于理解便于后面的人维护。对于一个过长的方法，我们就应该思考是否能拆分成几个职责不同、更有明确单一功能的函数。
四、优点
只要是模块化的程序设计，都适用单一职责原则。
优点：
(1) 可以降低类的复杂度，一个类只负责一项职责，其逻辑比有多项职责的类简单的多；
(2) 提高类的可读性，提高系统的可维护性；
(3) 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
缺点：
(1) 可能会使项目文件规模变大。“职责”没有一个明确的划分标准，如果把职责划分的太细的话会导致接口和实现类的数量剧增，反而提高了复杂度，降低了代码的可维护性。
五、示例