权力越大职责越大——C#中的职责链模式

大家好，欢迎来到老胡的博客，今天我们继续了解设计模式中的职责链模式，这是一个比较简单的模式。跟往常一样，我们还是从一个真实世界的例子入手，这样大家也对这个模式的应用场景有更深刻的理解。
 

一个真实的栗子

作为上班族，相信大家对请假都不陌生，每个公司都有自己请假的流程，稍微讲究点的公司还会有细致的规定，比如，3天以内的假期，小组长有权力批准，3天以上的假期就要找更高级别的领导批准。这种制度就是典型的权力越大职责越大——毕竟，批长假的职责只在高级主管那里存在。

除了规定出这样细致的要求之外，大部分公司还有用软件实现了请假流程，当请假人员提出请假申请的时候，会依据请假天数，转发给具有权限的人员审批，让我们看看这个系统的代码实现吧。
 

请假系统实现

在这个系统中，我们假定：

• 小组长可以审批3天以内的请假请求
• 部门经理可以审批5天以内的请假请求
• 10天以内的请假请求只有老板才能审批
• 我们同时假定，这个公司的管理层非常人性化，请假都能得到批准，除非大于10天，因为这种情况没人可以审批
   

请假申请

这是最简单的类，封装了请假天数和请假申请人

class VacationRequest
{
    public int DayNum { get; set; }
    public string RequesterName { get; set; }
}

 

假期审批者

首先创建一个抽象类，假期审批者，封装假期审批的基本逻辑，即，如果当前人员有权限审批当前假期申请，就处理

abstract class VacationApprover
{
    protected VacationApprover(int dayCanHandle)
    {
        DayCanHandle = dayCanHandle;
    }

    public int DayCanHandle { get; protected set; }

    public void HandleVacationRequest(VacationRequest request)
    {
        if (request.DayNum <= DayCanHandle)
        {
            DoHandleVacationRequest(request);
        }
    }

    protected abstract void DoHandleVacationRequest(VacationRequest request);
}

当然，抽象类只需要确定算法骨架，限定只有当前人员能处理这个请求的时候，才进行审批工作，至于具体的审批实现，留给子类自己去覆盖，这种在父类固定算法骨架，暴露部分覆盖点给子类的做法，就是之前我们提到过的TemplateMethod模式
 

具体假期审批者

小组长，部门经理，老板，都在这里创建，他们分别处理能审批3、5、10天的请假申请

class TeamLeader : VacationApprover
{
    private const int DAY_CAN_HANDLE_TEAMLEADER = 3;
    public TeamLeader() : base(DAY_CAN_HANDLE_TEAMLEADER) { }

    protected override void DoHandleVacationRequest(VacationRequest request)
    {
        Console.WriteLine("Now team leader handle this request");
        Console.WriteLine("Team leader accept this request");
    }
}

class DepartmentLeader : VacationApprover
{
    private const int DAY_CAN_HANDLE_DEPARTMENTLEADER = 5;
    public DepartmentLeader() : base(DAY_CAN_HANDLE_DEPARTMENTLEADER) { }

    protected override void DoHandleVacationRequest(VacationRequest request)
    {
        Console.WriteLine("Now department leader handle this request");
        Console.WriteLine("Department leader accept this request");
    }
}

class Boss : VacationApprover
{
    private const int DAY_CAN_HANDLE_BOSS = 10;
    public Boss() : base(DAY_CAN_HANDLE_BOSS) { }

    protected override void DoHandleVacationRequest(VacationRequest request)
    {
        Console.WriteLine("Now boss handle this request");
        Console.WriteLine("Boss accept this request");
    }
}

 

请假审批系统

请假审批系统提供统一请假申请接口，内部通过请假天数决定哪个审批者参与审批

class VacationApproveSystem
{
    private VacationApprover teamLeader = new TeamLeader();
    private VacationApprover departmentLeader = new DepartmentLeader();
    private VacationApprover boss = new Boss();

    public void HandleVacationRequest(VacationRequest request)
    {
        Console.WriteLine("Now handle {0}'s {1} days' vacation request", request.RequesterName, request.DayNum);

        if (request.DayNum <= teamLeader.DayCanHandle)
        {
            teamLeader.HandleVacationRequest(request);
        }
        else if (request.DayNum <= departmentLeader.DayCanHandle)
        {
            departmentLeader.HandleVacationRequest(request);
        }
        else if (request.DayNum <= boss.DayCanHandle)
        {
            boss.HandleVacationRequest(request);
        }
        else
        {
            Console.WriteLine("Cannot handle this request after all");
        }
    }
}

 

测试代码

class Program
{
    static void Main(string[] args)
    {
        VacationApproveSystem system = new VacationApproveSystem();

        system.HandleVacationRequest(new VacationRequest() { DayNum = 5, RequesterName = "laohu" });

        system.HandleVacationRequest(new VacationRequest() { DayNum = 10, RequesterName = "laohu" });

        system.HandleVacationRequest(new VacationRequest() { DayNum = 12, RequesterName = "laohu" });
    }
}

结果显示

一切都是正常的，当5天时，部门经理审批，10天时，老板审批，大于10天无人能批。 Good job。
 

回头看看

实现了第一版代码之后，我们再回过头看看，虽然代码功能无误，但是VacationApproveSystem似乎承担了过多的职责，它不但需要提供统一的请假审批接口给最终用户，它同时还需要知道每个请假审批者能审批的请假天数并在内部实现请假请求转发给不同审批者的逻辑。这样既违反了迪米特法则——它知道的太多了，也违反了开闭原则——如果任何一个审批者修改了自身能审批的请假天数，这个类都会被波及，最后，它还违反了单一职责——一个类只能有一个引起变化的原因。

有鉴于此，我们这版代码只能算凑合用，但远远谈不上结构良好，老老实实地重构代码吧，下面请出我们今天的主角。
 

职责链模式

乍一听有点生涩，翻译一下就是

• 解耦具体对象和请求——不要预先指定哪个对象来处理此请求（因为很多时候并不知道）
• 使多个对象都有机会——有一众候选对象，具体使用哪个对象是在运行时决定的
• 连成链传递请求——像链表一样，要在对象中体现出对象之间的链关系，而不要通过其他类以if..else的方式实现

所以，这么看来这个模式和我们的例子简直是绝配，我们已经做了大部分的工作了，现在剩下的就只是修改审批者，让审批者能链起来
 

代码重构

修改请假审批基类

最重要的改动，就是修改基类，让对象能链起来，在VacationApprover中添加一个后继节点和一个设置后继节点的方法。同时在基类的审批方法中，完成请求传递，即，如果请假申请超过了当前审批人的能力范围，则转发至后继节点。修改后的类如下

abstract class VacationApprover
{
    private VacationApprover nextVacationApprover = null;

    public void SetNextVacationApprover(VacationApprover approver)
    {
        nextVacationApprover = approver;
    }

    protected VacationApprover(int dayCanHandle)
    {
        DayCanHandle = dayCanHandle;
    }

    public int DayCanHandle { get; protected set; }

    public void HandleVacationRequest(VacationRequest request)
    {
        if (request.DayNum <= DayCanHandle)
        {
            DoHandleVacationRequest(request);
        }
        else
        {
            if(nextVacationApprover != null)
            {
                nextVacationApprover.HandleVacationRequest(request);
            }
            else
            {
                Console.WriteLine("Cannot handle this request after all");
            }
        }
    }

    protected abstract void DoHandleVacationRequest(VacationRequest request);
}

 

修改请假审批系统

基类重构结束之后，请假审批系统就可以瘦身了，删除了所有判断逻辑，仅仅在构造函数里面完成链组建的工作，接着一键调用，齐活。

class VacationApproveSystem
{
    private VacationApprover teamLeader = new TeamLeader();
    private VacationApprover departmentLeader = new DepartmentLeader();
    private VacationApprover boss = new Boss();

    public VacationApproveSystem()
    {
        teamLeader.SetNextVacationApprover(departmentLeader);
        departmentLeader.SetNextVacationApprover(boss);
    }

    public void HandleVacationRequest(VacationRequest request)
    {
        Console.WriteLine("Now handle {0}'s {1} days' vacation request", request.RequesterName, request.DayNum);

        teamLeader.HandleVacationRequest(request);
    }
}

 

测试

其他请假审批子类和测试客户端都不需要改动，这次重构工作量非常小，运行代码，一切正常，重构成功。
 

总结

这就是职责链模式的使用。和状态模式有点像，解决了以下问题：

• 通过添加子类把一些逻辑判断从调用类（VaccationApproveSystem）移到子类的方式，使得调用类满足迪米特法则
• 想在职责链上面添加更多节点的时候，只需要添加新类和修改链组装部分的代码，基本满足开闭原则（这里几乎不可能完全满足开闭原则，毕竟有修改就意味着我们肯定会改动VaccationApproveSystem类，只是我们应该尽量的让代码改动量少，以提高控制代码变动的能力）

和状态模式一样，它也有子类爆炸的风险。

可能有朋友会感到疑惑，既然职责链模式和状态模式看起来那么像，那它们有什么区别呢？它们的区别在于：

• 状态模式中的对象是有状态的，可以随时通过接口查询对象的当前状态，对象正是因为有了不同的状态，才会表现出不同行为。而职责链模式中的对象没有状态，对象和链的关系更像请求和处理管线的关系，没有接口能告诉我们当前在处理管线的哪个节点，也没有意义这么做，我们只关心请求是否被处理了
• 状态模式中的状态切换可以是无序的，比如，一个游戏角色，当他的状态是虚弱的时候，可以通过治疗，转换成健康，也可以通过受伤转换成濒死。而职责链中的请求转发就只有向前一条路，从小组长到部门经理，从部门经理到老板

根据不同的情景，选择合适的模式，才是正确的使用之道。以上就是今天的内容，希望大家喜欢，我们下次见！