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

单一职责原则

单一职责原则的英文名称是Single Responsibility Principle,简称SRP.

定义

单一职责的定义是：

There should never be more than one reason for a class to change.

应该有且仅有一个原因引起类的变更。

举例

例如IUserInfo接口定义如下：

IUserInfo
+void setUserID(String userID)
+String getUserID()
+void setPassword(String password)
+String getPassword()
+void setUserName(String userName)
+String getUserName()
+boolean changePassword(String oldPassword)
+boolean deleteUser()
+void mapUser()
+boolean addOrg(int orgID)
+boolean addRole(int roleID)

这个接口按照单一职责的原则进行拆分，将用户信息抽取成一个BO(Business Object,业务对象)，将用户行为抽取成一个Biz(Business Logic,业务逻辑)

IUserBO
+void setUserID(String userID)
+String getUserID()
+void setPassword(String password)
+String getPassword()
+void setUserName(String userName)
+String getUserName()

IUserBiz
+boolean changePassword(String oldPassword)
+boolean deleteUser()
+void mapUser()
+boolean addOrg(int orgID)
+boolean addRole(int roleID)

IUserInfo接口继承IUserBO和IUserBiz

分清职责后的代码示例：

......
IUserInfo userInfo = new UserInfo();
//我要赋值了，我就认为它是一个纯粹的BO
IUserBO userBO = (IUserBO)userInfo;
userBO.setPassword("abc");
//我要执行动作了，我就认为是一个业务逻辑类
IUserBiz userBiz = (IUserBiz)userInfo;
userBiz.deleteUser();
......

注意点：

单一职责原则最难划分的就是职责。一个职责一个接口，但问题是“职责”没有一个量化的标准，一个类到底要负责那些职责？这些职责该怎样细化？细化后是否都要有一个接口或类？这些都需要从实际的项目去考虑。

对于接口，我们在设计的时候一定要做到单一，但是对于实现类酒需要多方面考虑了。生搬硬套单一职责原则会引起类的剧增，给维护带来非常多的麻烦，而且过分细分类的职责也会人为地增加系统的复杂性。本来一个类可以实现的，硬要拆成两个类，然后再使用聚合或组合的方式藕合在一起，人为地制造了系统的复杂性。所以原则是死的，人是活的，这句话很有道理。

单一职责适用于接口，类，同时也适用于方法，什么意思呢？一个方法尽可能只做一件事情，比如一个方法修改用户密码，不要把这个方法放到“修改用户信息”方法中，这个方法点颗粒度很粗，比如下面这个方法：

//一个方法承担多个职责
void changeUser(IUserBO userBO,String..changeOptions)

相比较而言，比较好的写法应该是这样的：

void changeUserName(String newUserName)
void changeHomeAddress(String newHomeAddress)
void changeOfficeTel(String telNumber)

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