C++与设计模式(14)——职责链模式

职责链模式

使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系

让我来描述的话就是,现在我们有很多的对象可以处理一个事件,但这个事件的拥有者并不需要认识所有处理它事件的对象,这个时候就需要责任链模式来解决。
比如需要向公司请假,一天的假期只需要向组长申请就可以了,而一周甚至更长的假期则需要上级领导的批准。把这个例子写成代码:

class Manager
{
public:
    Manager(Manager *superior):m_superior(superior){}
    virtual bool deelWithLeave(int day) = 0;

protected:
    Manager *m_superior;
};

class GroupLeader : public Manager
{
public:
    GroupLeader(Manager *superior):Manager(superior){}
    virtual bool deelWithLeave(int day)
    {
        if(day <= 1)
        {
            cout << "组长批准请假" << day << "天";
            return 1;
        }
        else//权限不够,向上级汇报
            return m_superior->deelWithLeave(day);
    }
};
class Director : public Manager
{
public:
    Director(Manager *superior):Manager(superior){}
    virtual bool deelWithLeave(int day)
    {
        if(day <= 7)
        {
            cout << "主任批准请假" << day << "天";
            return 1;
        }
        else
            return m_superior->deelWithLeave(day);
    }
};
class GeneralManager : public Manager
{
public:
    GeneralManager(Manager *superior):Manager(superior){}
    virtual bool deelWithLeave(int day)
    {
        cout << "总经理批准请假" << day << "天";
        return 1;
    }
};

使用

GeneralManager generalManager(nullptr);
Director director(&generalManager);
GroupLeader myLeader(&director);

myLeader.deelWithLeave(20);

优缺点

优点

  1. 在责任链模式下,事件处理者们的结构对于事件发送者是未知的,无论处理者们的结构是单链或者树状的、最后一定会被执行或没有人来处理,具体的过程对于事件发送者就是一个黑盒子,事件发送者只需要简单的向自己上级汇报就可以了。
  2. 责任链模式实际上是非常灵活的,我们可以提供接口,使每个人的上级都是动态的,比如主任有事出去,那么主任就可以把总经理的联系方式交给组长,请假的审批仍然可以继续进行,而请假的人却不需要知道这一点。

缺点

  1. 当我要请一个30天的假时,你会发现在这个过程中组长和主任只是承担了一个传递信息的责任,如果我们的责任链过长,那么中间会有许多垃圾对象存在。
  2. 易被滥用,在一些情况下,我们可以直接创建一个对象来处理请求:
class LeaveHandler
{
public:
    bool deelWithLeave(int day)
    {
        if(day <= 1)
            cout << "向组长请假";
        else if(day <= 7)
            cout << "向主任请假";
        else
            cout << "向总经理请假";
    }
};

在公司的管理体制不会出现变化的情况下,这样做反而更好。

实际应用

事实上在qt的事件系统中就使用了责任链模式,当一个点击事件产生时,它会在子控件和父控件之间传递来寻求处理方案。这里可能处理完后事件就被拦截,也可能处理完好继续交给下一位去处理,我们可以通过重载对应的事件函数或event函数来改写处理过程。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值