单一职责原则
单一职责原则的英文名称是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 | ...... |
注意点:
单一职责原则最难划分的就是职责。一个职责一个接口,但问题是“职责”没有一个量化的标准,一个类到底要负责那些职责?这些职责该怎样细化?细化后是否都要有一个接口或类?这些都需要从实际的项目去考虑。
对于接口,我们在设计的时候一定要做到单一,但是对于实现类酒需要多方面考虑了。生搬硬套单一职责原则会引起类的剧增,给维护带来非常多的麻烦,而且过分细分类的职责也会人为地增加系统的复杂性。本来一个类可以实现的,硬要拆成两个类,然后再使用聚合或组合的方式藕合在一起,人为地制造了系统的复杂性。所以原则是死的,人是活的,这句话很有道理。
单一职责适用于接口,类,同时也适用于方法,什么意思呢?一个方法尽可能只做一件事情,比如一个方法修改用户密码,不要把这个方法放到“修改用户信息”方法中,这个方法点颗粒度很粗,比如下面这个方法:
1 | //一个方法承担多个职责 |
相比较而言,比较好的写法应该是这样的:
1 | void changeUserName(String newUserName) |
对于单一职责原则,笔者的建议是接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。