设计模式 —— 单一职责原则

最新推荐文章于 2023-01-11 18:39:11 发布

Jecklin_online

最新推荐文章于 2023-01-11 18:39:11 发布

阅读量324

点赞数

分类专栏：设计模式文章标签：设计模式 c

本文链接：https://blog.csdn.net/jecklin_online/article/details/82686920

版权

设计模式专栏收录该内容

23 篇文章 1 订阅

订阅专栏

前言
单一职责原则的定义：应该有且仅有一个原因引起类的变更
单一职责原则的英文名称是： Single Responsibility Principle，简称是 SRP。

6大设计原则：

单一职责原则
里氏替换原则
依赖倒置原则
接口隔离原则
迪米特法则
开闭原则

当在项目中，接触到用户、机构、角色管理这些模块，基本使用的都是RBAC 模型（ Role- Based Access Control，基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）与资源的行为（权限）分离）。

示例一：

场景：用户管理、修改用户的信息、增加机构（一个人属于多个机构）、增加角色等，用户有这么多的信息和行为要维护

1. 修改前的版本：

接口设计类图如图 1- 1 所示。

问题：用户的属性和用户的行为没有分开

2. 修改后的版本：
修改：把用户信息抽取成一个 BO（ Business Object，业务对象），把行为抽取成一个 Biz（ Business Logic，业务逻辑）。重新拆封成两个接口， IUserBO 负责用户的属性，简单地说， IUserBO 的职责就是收集和反馈用户的属性信息； IUserBiz 负责用户的行为，完成用户信息的维护和变更。

解析：我们现在是面向接口编程，所以产生了这个 UserInfo 对象之后，当然可以把它当 IUserBO 接口使用。也可以当 IUserBiz 接口使用，这要看你在什么地方使用了。要获得用户信息，就当是 IUserBO 的实现类；要是希望维护用户的信息，就把它当作 IUserBiz 的实现类就成了，类图如图 1- 2 所示。

代码清单：

class IUserBO
{
public:
    void    setUserID(string userID);
    string  getUserID();
    void    setPassword(string password){}
    string  getPassword();
    void    setUserName(string userName);
    string  getUserName();
};

class IUserBiz
{
public:
    bool    changePassword(string password);
    bool    deleteUser(IUserBO userBO){return true;}
    void    mapUser(IUserBO userBO);
    bool    addOrg(IUserBO userBO, int orgID);
    bool    addRole(IUserBO userBO, int roleID);
};

class IUserInfo:public IUserBO, public IUserBiz
{
    
};

class UserInfo:public IUserInfo
{
    
};


int main ()
{
    //c++中可以使用多继承，java是单继承，这里有区别
    IUserInfo userInfo;
    userInfo.setPassword("abc");
    IUserBO userBO;
    userInfo.deleteUser(userBO);

    return 0;
}

分析：
为什么要把一个接口拆分成两个呢？依赖了单一职责原则。

示例二：

场景：电话的使用，电话通话的时候有4个过程发生：拨号、通话、回应、挂机

1. 修改前的版本：类图如图1-4所示

代码清单：

class Object;

class IPhone
{
public:
    void    dial(string phoneNumber); //拨通电话
    void    chat(Object o);           //通话
    void    hangup();                 //通话完毕，挂电话
};

问题： IPhone 这个接口可不是只有一个职责，它包含了两个职责：一个是协议管理，一个是数据传送。 dial() 和 hangup() 两个方法实现的是协议管理，分别负责拨号接通和挂机； chat() 实现的是数据的传送，把我们说的话转换成模拟信号或数字信号传递到对方，然后再把对方传递过来的信号还原成我们听得懂的语言。

2. 修改一次的版本：
我们可以这样考虑这个问题，协议接通的变化会引起这个接口或实现类的变化吗？会的！那数据传送（想想看，电话不仅仅可以通话，还可以上网）的变化会引起这个接口或实现类的变化吗？会的！那就很简单了，这里有两个原因都引起了类的变化。这两个职责会相互影响吗？电话拨号，我只要能接通就成，甭管是电信的还是网通的协议；电话连接后还关心传递的是什么数据吗？通过这样的分析，我们发现类图上的 IPhone 接口包含了两个职责，而且这两个职责的变化不相互影响，那就考虑拆分成两个接口，
职责分明的电话类图如图 1- 5 所示。

3. 修改后的版本
这个类图看上去有点复杂了，完全满足了单一职责原则的要求，每个接口职责分明，结构清晰，但是我相信你在设计的时候肯定不会采用这种方式，一个手机类要把 ConnectionManager 和 DataTransfer 组合在一块才能使用。组合是一种强耦合关系，你和我都有共同的生命期，这样的强耦合关系还不如使用接口实现的方式呢，而且还增加了类的复杂性，多了两个类。经过这样的思考后，我们再修改一下类图，
简介清晰、职责分明的电话类图如图 1- 6 所示。

分析：一个类实现了两个接口，把两个职责融合在一个类中。你会觉得这个 Phone 有两个原因引起变化了呀，是的，但是别忘记了我们是面向接口编程，我们对外公布的是接口而不是实现类。而且，如果真要实现类的单一职责，这个就必须使用上面的组合模式了，这会引起类间耦合过重、类的数量增加等问题，人为地增加了设计的复杂性。

总结：单一职责原则的好处：

● 类的复杂性降低，实现什么职责都有清晰明确的定义；
● 可读性提高，复杂性降低，那当然可读性提高了；
● 可维护性提高，可读性提高，那当然更容易维护了；
● 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

注：单一职责原则提出了一个编写程序的标准，用“ 职责” 或“ 变化原因” 来衡量接口或类设计得是否优良，但是“ 职责” 和“ 变化原因” 都是不可度量的，因项目而异，因环境而异。

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

参考文献《秦小波. 设计模式之禅》（第2版） (华章原创精品) (Kindle 位置 308-310). 机械工业出版社