设计模式之禅之单一职责原则

声明：本文为阅读秦小波所写的《设计模式之禅》所写小结，文章内容可能有部分引述此书。

单一职责原则(Single Responsibility Principle)

1、定义：

在接口、方法的定义上，需要单一职责，一个接口就只干一类事情，一个方法只干一件事情。此原则中心要义：有且仅有一个原因引起类的变更。

在项目上，对于用户角色管理这块，一般是基于RBAC模型：Role-Based Access Control 基于角色的访问控制。它的定义是：通过分配和取消角色来完成用户权限的授予和取消，使动作主体(用户)与资源行为(权限)分离。

BO：Business Object 业务对象 ---- 负责属性
BIZ：Business Logic 业务逻辑 ---- 负责行为

RBAC模型就符合了单一职责原则，将业务对象和业务逻辑分离，彼此只干属于自己的这一类事情，职责清晰，彼此不干涉。但彼此聚合起来又能完成业务的处理。

举例：

interface IUserManager{....../*** 修改用户信息* @param userName  用户名* @param homeAddress 用户地址* @param telNumber 用户手机号*/public void changeUser(String userName, String homeAddress, String telNumber){//业务逻辑处理}......
}

以上changeUser方法就不符合单一职责原则，一个方法干了修改用户名，用户地址和手机号的三件事，造成了方法职责不清晰。一旦某人电话号码或者地址变了，还需要再次调用这个方法，将三个信息同时再次输入进去，同时也增大了日后维护的工作量。

进行修改处理：

interface IUserManager{....../*** 修改用户名* @param userName  用户名*/public void changeUserName(String userName){//业务逻辑处理}/*** 修改用户地址* @param homeAddress 用户地址*/public void changeHomeAddress(String homeAddress){//业务逻辑处理}/*** 修改用户手机号* @param telNumber 用户手机号*/public void changeUserTelNumber(String telNumber){//业务逻辑处理}......
}

这样修改之后，方法一目了然，知道每个方法都是具体干什么事情，后期维护一旦有相应变化时，只需调用专门负责的方法进行修改即可。

2、单一职责的好处：

1）类的复杂度降低：实现什么职责都有明确清晰的定义，这个在接口上定义时特别要区分清楚；
2）可读性提高了：知道某个接口具体做哪件事；
3）可维护性提高了：知道这个接口只做这件事；
4）变更影响的风险降低了：接口的改变只对实现类有影响，对其他接口无影响。

3、如何使用？

在接口定义上，要清楚该接口的职责，只干一件事，不要一个接口揽多个活。

小结：接口以及方法一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

注：本文大多数内容基本从《设计模式之禅中》摘录，也有小部分自己的理解，如果有误欢迎大家批评指正。如有问题，也欢迎大家积极留言探讨。