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

单一职责原则

单一职责原则的英文名称是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

分清职责后的代码示例:

1
2
3
4
5
6
7
8
9
......
IUserInfo userInfo = new UserInfo();
//我要赋值了,我就认为它是一个纯粹的BO
IUserBO userBO = (IUserBO)userInfo;
userBO.setPassword("abc");
//我要执行动作了,我就认为是一个业务逻辑类
IUserBiz userBiz = (IUserBiz)userInfo;
userBiz.deleteUser();
......

注意点:

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

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

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

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

相比较而言,比较好的写法应该是这样的:

1
2
3
void changeUserName(String newUserName)
void changeHomeAddress(String newHomeAddress)
void changeOfficeTel(String telNumber)

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

坚持原创技术分享,您的支持将鼓励我继续创作!