单一职责原则

---

定义：应该有且仅有一个原因引起类的变更。

英文名称：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

单一职责原则的优点：

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

• 可读性提高
• 可维护性提高
• 变更引起的风险降低，因为一个接口修改只对应的实现类有影响，对其他的接口无影响，这对系统的扩展性，维护性都有非常大的帮助

建议：

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

• 但对于接口一定要做到单一职责，对于类的设计尽量做到只有一个原因引起变化。