定义：应该有且仅有一个原因引起类的变更。
英文名称：Single Responsibility Principle， 简称SRP
原文：There should never be more than one reason for a class to change
用户信息实例：
a. 设计一个接口作为存储用户属性以及用户行为
UserInfo.png
明显这样的设计是杂乱的，因为它没有将用户的属性和行为分开！
b. 将用户的信息抽取成一个BO(Business Object 业务对象)，把行为抽取成一个Biz(Business Logic 业务逻辑)
UserInfo.png
这样IUserBO负责用户的属性，即收集和反馈用户的属性信息；IUserBiz负责用户的行为，完成用户信息的维护和变更。
电话实例：
a. 我们设计一个接口IPhone来实现拨号，通话，挂机
phone.png
这样的设计看起来是符合单一职责的，但实际上也并不完全是。我们知道要符合单一原则，必须满足只有一个原因引起变化。
而实际上，目前的设计是存在两个职责：一个是协议管理，一个是数据传送。
其中dial()和hangup()实现的是协议管理，chat()实现的是数据传递。
因此，我们考虑将这个接口再细分为两个接口，以负责不同的职责
phone.png
这样的设计实现了一个类实现了两个接口，将两个职责融合在一个类中。你可能会觉得phone类有两个原因引起变化的，但实际上，我们是面向接口编程，对外公布的是接口而不是类。
单一职责适用于接口，类，同时也适用于方法。
比如我们定义一个方法修改用户信息
method.png
这样的设计明显不理想，因为当如果我们只需要修改一个属性，也去改变其他属性，因此，最好的方法是一个方法承担一个职责。
method.png
单一职责原则的优点：
- 类的复杂性降低，实现什么职责都有清晰明确的定义。
- 可读性提高
- 可维护性提高
- 变更引起的风险降低，因为一个接口修改只对应的实现类有影响，对其他的接口无影响，这对系统的扩展性，维护性都有非常大的帮助
建议：
- 单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。
- 但对于接口一定要做到单一职责，对于类的设计尽量做到只有一个原因引起变化。
