单一职责原则 (2)

类这个看了一些资料都说没法硬性要求一定按单一职责原则分，或者说类的职责可大可小，没有很明确的像上面接口那样按照单一职责原则分就很清晰也很有道理。
设想一下这个场景：我们要实现一个用户注册、登录、注销操作，可以像如下 2 种实现方式
代码：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 设计模式》