一、单一指责原则(single responsibility principle,SRP)
什么是类的职责?以及怎么划分类的职责
1、单一指责的定义:应该有且仅有一个原因引起类的变更。 变化的原因就是所说的"职责"。
2、如果一个类有多个引起它变化的原因,也就意味着这个类有多个职责。即把多个职责耦合在一起了。
3、“职责”的粒度不好量化。实际开发中,这个原则最容易违反
二、单一指责的优点
1、类的复杂性降低,一个类负责一项职责,实现什么职责都有清晰明确的定义。
2、提高类的可读性和可维护性
3、变化引起的风险降低,变化是必然的,如果接口的单一指责做得好,一个接口的修改只会对相应的实现类有影响,对其他接口无影
响,对系统的扩展性、维护性有好处。
三、实例分析
1、用户管理类的实现
只要做过项目,肯定接触过用户、机构、角色管理这些模块,基本上使用RBAC模型(基于角色的访问控制,通过分配和取消角色来完
成用户权限的授予和取消,是动作主体 用户 与 资源的行为 权限 分离),确实是很好的解决方法。
(1)、臃肿的接口设计
用户管理类,通过一个接口实现。
接口设计的问题:用户的属性和用户的行为没有分开,严重的错误!我们应该把用户的信息抽取成一个BO(Business Object业务对
象),把行为抽取成一个Biz(Business Logic业务逻辑),按照这个思路进行接口设计:
(2)、职责分离
为什么要把一个接口拆分成两个呢?实际使用中,我们更倾向于使用两个类或接口,一个是IUserBO,一个是IUserBiz。就是依赖单
一指责原则。 java中实现可以是依赖的关系,但是C++中实现是关联 或者 聚合应该都可以。
(3)根据类图代码实现(如果能清晰的看懂类图,代码实现起来还是很简单的)
#include <iostream> #include <string> using namespace std; //业务对象抽象类 class IUserBO { public: virtual void setUserID(string userID) = 0; virtual string getUserID() = 0; virtual void setPassword(string password) = 0; virtual string getPassword() = 0; virtual void setUserName(string userName) = 0; virtual string getUsername() = 0; }; class UserBO : public IUserBO { private: string userID; string userName; string passWD; public: UserBO(string userid,string username,string passwd) { userID = userid; userName = username; passWD = passwd; } UserBO(const UserBO& object) { userID = object.userID; userName = object.userName; passWD = object.passWD; } UserBO& operator = (const UserBO& object) { if (this != &object) { userID = object.userID; userName = object.userName; passWD = object.passWD; } return *this; } void setUserID(string userID) { this->userID = userID; } string getUserID() { return userID; } void setPassword(string password) { this->passWD = password; } string getPassword() { return passWD; } void setUserName(string userName) { this->userName = userName; } string getUsername() { return userName; } }; //业务逻辑抽象类 class IUserBiz { public: virtual bool changePassword(string passwd) = 0; virtual bool deleteUser(string username) = 0; virtual bool addOrg(int orgID) = 0; virtual bool addRole(int roleID) = 0; }; class UserBiz : public IUserBiz { private: IUserBO* userBO; public: UserBiz(IUserBO* object) { userBO = object; } bool changePassword(string passwd) { bool rtn = true; if (userBO->getPassword() != passwd) { userBO->setPassword(passwd); cout << "修改密码成功!" << endl; } else { rtn = false; } return rtn; } bool deleteUser(string username) { bool rtn = true; if (userBO->getUsername() != username) { rtn = false; } else { cout << "删除用户成功!" << endl; } return rtn; } bool addOrg(int orgID) { cout << "自行实现!" << endl; return true; } bool addRole(int roleID) { cout << "自行实现!" << endl; return true; } }; int main(void) { UserBO* userBO = new UserBO("1","spach","lixin101357"); //用户逻辑类对象可以对这个进行处理 IUserBiz* userbiz = new UserBiz(userBO); if (userbiz->changePassword("helloworld")) { cout << userBO->getPassword() << endl; } cin.get(); return 0; }
2、电话类图
电话通话的时候有四个过程:拨号、通话、回应、挂机,我们实现一个接口:类图如下所示:请忽视图是截过来的,重点是分析
拨通电话、通过、通话完毕挂电话
单一职责要求一个接口或类只有一个原因引起变化,也就是一个接口或类只有一个职责,负责一件事情,貌似上面的类不是这样的。
Iphone接口两个职责:协议管理、数据传送。dial()和hangup()实现的事协议管理,分别负责拨号接通和挂机;chat()实现的是数据传送。
我们可以这样考虑问题:协议接通的变化会引起接口或类的变化,数据传送也会引起类或接口的变化。两个原因都引起了类的变化。但是两个职责会相
互影响吗?不会的。
类图上的IPhone接口包括两个职责,而且职责的变化不会相互影响,那就可以考虑两个接口,类图如下所示:
一个手机类要把ConnectionManager和DataTransfer组合在一块才能使用。组合是强耦合关系,共同的生命周期,这样的强耦合关系还不如使用接口实
一个类实现两个接口,把两个职责融合在一个类中。你会觉得这个Phone有两个原因引起变化,是的,但是别忘了我们是面向接口编程的,对外公布的
是接口而不是实现类。而且,如果真的要实现类的单一指责原则,必须使用上面的组合模式,会引起类间耦合过重、类数量增加等问题,人为增加设计
的复杂性。
四、总结
1、单一指责原则适用于类、接口,同时也适用于方法。一个方法尽可能做一件事情。
方法职责不清晰,不单一,不要让别人猜测这个方法是用来处理什么逻辑的。
2、建议接口一定要做到单一指责,类的设计尽量做到只有一个原因引起变化。
原文链接:https://www.f2er.com/javaschema/283585.html