单一职责原则 - 好文

个人博客原文：
单一职责原则 <http://www.liebrother.com/single-responsibility-principle>

设计模式六大原则之一：单一职责原则

简介

姓名：单一职责原则
英文名：Single Responsibility Principle
座右铭：There should never be more than one reason for a class to change.
应当有且仅有一个原因引起类的变更。。。意思就是不管干啥，我都只干一件事，你叫我去买菜，我就只买菜，叫我顺便去倒垃圾就不干了，就这么拽
脾气：一个字“拽”，两个字“特拽“
伴侣：老子职责单一，哪来的伴侣？
个人介绍
：在这个人兼多责的社会里，我显得那么的特立独行，殊不知，现在社会上发生的很多事情都是因为没有处理好职责导致的，比如，经常有些父母带着小孩，一边玩手机，导致小孩弄丢、发生事故等等

单一职责应用范围

单一职责原则适用的范围有接口、方法、类。按大家的说法，接口和方法必须保证单一职责，类就不必保证，只要符合业务就行。

方法

设想一下这个场景：假设我们要做一个用户修改名字以及修改密码的功能，可以有多种实现方案，比如下面列举 2 种实现方式
代码：SrpOfMethod.java
<https://github.com/1CSH1/DesignPatterns/blob/master/src/com/liebrother/designpatterns/srp/SrpOfMethod.java>

第一种实现方式
/** * 错误的示范 */ enum OprType { /** * 更新密码 */ UPDATE_PASSWORD, /** * 更新名字 */
UPDATE_NAME; } interface UserOpr { boolean updateUserInfo(User user, OprType
oprType); } class UserOprImpl implements UserOpr { @Override public boolean
updateUserInfo(User user, OprType oprType) { if (oprType ==
OprType.UPDATE_NAME) { // update name } else if (oprType ==
OprType.UPDATE_PASSWORD) { // update password } return true; } }
第二种实现方式
/** * 正确的示范 */ interface UserOpr2 { boolean updatePassword(User user, String
password); boolean updateUserInfo(User user); } class UserOprImpl2 implements
UserOpr2 { @Override public boolean updatePassword(User user, String password)
{ user.setPassword(password); // update password return true; } @Override
public boolean updateUserInfo(User user) { // update user info return true; } }
2 种实现有什么区别呢？第一种实现通过 OprType
类型的不同来做不同的事情，把修改密码和修改名字耦合在一起，容易引起问题，只要稍不注意，传错枚举值就悲剧了，在代码中也没法很直接看到是做什么操作，也就是这个方法的职责不明确。而第二种实现，把修改密码和修改名字分离开来，也就是把修改密码和修改名字都当做独自的职责处理，这样子就很清晰明了，你调用哪个方法，就很明确的知道这个方法是实现什么逻辑。结论是啥呢？用第二种方式实习才符合单一职责原则。现实中看到很多像第一种实现的代码，而且是枚举有十来个的情况，看代码真费劲。

接口

设想一下这个场景，假设我们让小明去倒垃圾，小红去买菜，小红回来后再叫小红去洗碗。下面也举 2 个实现的例子。
代码：SrpOfInterface.java
<https://github.com/1CSH1/DesignPatterns/blob/master/src/com/liebrother/designpatterns/srp/SrpOfInterface.java>

第一种实现方式
/** * 错误的示范 */ interface Housework { void shopping(); void pourGarbage(); }
class XiaoMing implements Housework { @Override public void shopping() { // 不购物
} @Override public void pourGarbage() { System.out.println("pourGarbage ...");
} } class XiaoHong implements Housework { @Override public void shopping() {
System.out.println("shopping ..."); } @Override public void pourGarbage() { //
从不倒垃圾 } }
中途回来小红去洗碗，要怎么实现？按这个写法，就在 Housework 接口添加 washingUp()
方法，然后小明和小红依次都实现洗碗这个方法，只是小明不做具体实现代码，这样子是不是觉得很别扭，不符合单一职责原则的，修改一个地方，不影响其他不需要改变的地方，只对需要用到的地方做修改。小明本来就不用洗碗，却要去实现洗碗这个方法。

第二种实现方式
/** * 正确的示范 */ interface Shopping { void doShopping(); } interface PourGarbage
{ void doPourGarbage(); } interface WashingUp { void doWashingUp(); } class
XiaoMing2 implements PourGarbage { @Override public void doPourGarbage() {
System.out.println("pourGarbage ..."); } } class XiaoHong2 implements Shopping,
WashingUp { @Override public void doShopping() { System.out.println("shopping
..."); } @Override public void doWashingUp() { System.out.println("washing up
..."); } }
可以看到，这种实现把不同的家务都当做不同的职责，分离开来，这种实现可以按需实现做家务的类型，小明只需要去倒垃圾，就实现 PourGarbage
接口，小红去购物和洗碗，就实现 Shopping 和 WashingUp 接口，完全不会影响到对方，这才是完美的根据单一职责原则编写出来的代码。

类

类这个看了一些资料都说没法硬性要求一定按单一职责原则分，或者说类的职责可大可小，没有很明确的像上面接口那样按照单一职责原则分就很清晰也很有道理。
设想一下这个场景：我们要实现一个用户注册、登录、注销操作，可以像如下 2 种实现方式
代码：SrpOfClass.java
<https://github.com/1CSH1/DesignPatterns/blob/master/src/com/liebrother/designpatterns/srp/SrpOfClass.java>

第一种实现方式

从用户的角度考虑，这些操作都是用户的行为，可以放在一个统一的类 UserBiz
class UserBiz { public boolean register(User user){ // 注册操作 return true; }
public boolean login(User user) { // 登录操作 return true; } public boolean
logout(User user) { // 注销操作 return true; } }
第二种实现方式

有人又说，不是说单一职责么？从业务操作考虑，需要把注册、登录、注销分开
class UserRegisterBiz { public boolean register(User user){ // 注册操作 return
true; } } class UserLoginBiz { public boolean login(User user) { // 登录操作 return
true; } } class UserLogoutBiz { public boolean logout(User user) { // 注销操作
return true; } }
感觉像是在抬杠，其实这个没有好坏之分，根据具体业务具体分析，你说你的登录、注册、注销操作代码很多，需要分开，那就分开，无可厚非。

好处

* 类的复杂性降低，实现什么职责都有清晰明确的定义
* 可读性提高，复杂性降低，那当然可读性提高了
* 可维护性提高，可读性提高，那当然更容易维护了
*
变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助
(来自《设计模式之禅》)
总结

这个单一职责原则，目的就是提高代码的可维护性、可读性、扩展性，如果为了单一职责而破坏了这 3 个特性，可能会得不偿失。

参考资料：《大话设计模式》、《Java设计模式》、《设计模式之禅》、《研磨设计模式》、《Head First 设计模式》

希望文章对您有所帮助，设计模式系列会持续更新，感兴趣的同学可以关注公众号，第一时间获取文章推送阅读，也可以一起交流，交个朋友。

公众号之设计模式系列文章
<https://mp.weixin.qq.com/mp/homepage?__biz=MzIxMzgwMTAyMg==&hid=2&sn=c97b64288d92312f57d3c8298f8d8888>

热门工具换一换