单一职责原则

1.1 我是“牛”类，我可以担任多职吗

单一职责原则，英文名称是 Single Responsibility Principle，简称是 SRP，定义是应该有且仅有一个原因引起类的变更。

什么是类的职责，以及怎么划分类的职责？

举例：rbac 模型

这个接口设计的存在问题：用户属性和用户行为没有分开

把用户信息抽取成一个 BO（Business Object，业务对象），把行为抽取成一个 Biz（Business Logic，业务逻辑），我们面向接口编程，所以产生的 UserInfo 对象可以当成 IUserBO 接口使用，也可以录成 IUserBiz 接口使用

IUserInfo userInfo = new UserInfo();IUserBO userBO = (IUserBO)userInfo;userBO.setPassword("abc");IUserBiz userBiz = (IUserBiz)userInfo;userBiz.deleteUser();

在实际使用中，我们更倾向于使用两个不同的类或接口，如下：

1.2 绝杀技，打破你的传统思维

举例：电话设计

这么设计的问题是 IPhone 接口不只有一个职责，分别为：一个是协议管理，一个是数据传送。

这样设计引起类间耦合过重、类的数量增加，人为地增加了设计的复杂性

这样设计，一个类实现两个接口，把两个职责融合在一个类中。

单一职责原则的好处

实现什么职责都有清晰明确的定义，这样类的复杂性降低，可读性提高，可维护性提高

1.3 我单纯，所以我快乐

单一职责适用于接口、类，同时也适用于方法。

要修改用户名称，就调用 changeUserName 方法；要修改家庭地址，就调用 changeHomeAddress 方法；要修改单位电话，就调用 changeOfficeTel 方法。每个方法的职责非常清晰明确，不仅开发简单，而且日后的维护也非常容易。

1.4 最佳实践

大部分情况下类设计都是与单一职责相违背的，类的单一职责受到非常多因素的制约，现实你必须去考虑项目工期、成本、人员技术水平、硬件情况、网络情况甚至有时候还要考虑政府政策、垄断协议等因素。

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

参考：

1. 《设计模式之禅》第 2 版