设计模式-单一职责原则

  单一职责原则（SRP：Single responsibility principle）又称单一功能原则，原话解释是：there should never be more than  a reason of a class to change ,也就是引起类的变化原因不能超过一个，面向对象五个基本原则（SOLID）之一。该原则由罗伯特·C·马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中给出的。马丁表示此原则是基于汤姆·狄马克(Tom DeMarco)和Meilir Page-Jones的著作中的内聚性原则发展出的。
所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离。如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强功能的内聚性。

  做过项目肯定知道系统都会有涉及到用户，机构，角色管理这些模块，现在都是基于RBAC（role-based access control）模式。也就是通过分配和取消角色来授予或取消用户权限，使动作主体（用户）和资源行为（角色）分离，这种基于角色的访问控制所遵循的原则就是SRP了，总体设计原则是遵循BO(business Ojbect)和BL(business Logic的观念。

从上图看出这个接口设计把用户信息和行为都写在一起，会有多个行为影响到此对象的变化，这种设计是非常不合理的，背离了单一职责理念，优化后如图所示：

从上图看出关系：IUserInfo接口继承于接口IUserInfo和IUserBiz，同时UserInfo类实现IUserInfo接口，这样的设计就符合面向接口编程和单一职责，但是 在实际中我们更可能如下图这样做：

这种设计看起来是不是非常简单明了，UserBo和UserBiz分别继承IUser和IUserBiz接口，IUserBiz依赖于IUser是不是so easy！确实是这样。

所以我们看出单一职责的优点：

1 代码的可维护性提高了，一个业务的变更不会影响到其他业务模块。

2 可读性提高，类的职责更加明确清晰。

3当涉及系统需求的变更，它所带来的风险指数会更低。