设计模式之职责链模式、减小了因为分支带来的耦合_责任链模式减少的原因-优快云博客

职责链模式通过建立处理请求的链式结构，减少了请求发送者与接收者间的耦合。文章以一个公司请假和加薪审批流程为例，展示了如何通过职责链模式重构代码，避免过多的分支判断，遵循单一职责原则，提高代码可维护性。通过创建抽象管理者类和具体管理者类，实现了请求沿链传递，降低了对象间的相互依赖。职责链模式的使用提高了系统的灵活性，但也需要注意请求可能未被处理或配置错误的问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. 定义

职责链模式(Chain of Responsibility)：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止

简单来说，就是以链的方式将自己不能解决的事情往下面传递，比方说，经理做不了的事情交给总监做，总监做不了的事情交给总经理做，也就是职责的传递，以链的形式传递

2. 举例

题目：在一个公司里，假设只处理请假或者加薪两种请求，总共3个负责人可以处理，即经理，总监，总经理，这3个职位各个作用是：

经理的作用：只管“请假”类型的请求，且批准请假的次数不多于2次

总监的作用：只管“请假”类型的请求，且只批准不大于5次的请假次数

总经理的作用：1.管“请假”类型的请求，可以批准任意天数的请假天数 2.管“加薪”类型的请求，且批准加薪小于等于500的金额，大于500的金额就不批准

解题思路：
如果我们只是把这三个职位放进去一个类通过判断职位来处理业务的话，那么太多的分支结构导致了后续的维护更改太难，太多的责任导致违反了单一职责模式；如果要新增或者修改，就要修改这个类，违反了开放-封闭原则

如下面代码所示：

在这里插入图片描述

上述职责耦合度太高，全放在一个类，太多的分支判断，需要修改就要改这个类，难维护

根据单一职责原则，我们于是需要将不同职责抽出来，而不是放在同一个类里；所以我们至少有3个职位，3个具体职位类，于是我们可以抽取其抽象类，让其他具体类来继承抽象类；我们发现不同职责的处理能力是有限的，这个请求无法处理就让上级处理，依次往上直到能处理，于是我们需要设置上级的方法，然后在客户端调用其方法为职位设置上级即可

其实，这就是职责链模式的思想，按照职责链，把分支拆开，降低耦合，方便维护

3. 以职责链模式重构例子

结构图：
在这里插入图片描述
代码：

创建申请类

 //申请类，包括申请内容、申请类别、申请数量
    class Request
    {
   
        //申请类别
        public string RequestType {
    get; set; }
        //申请内容
        public string RequestContent {
    get; set; }
        //申请数量
        public int Number {
    get; set; }
    }

创建抽象类，即抽象管理者类

//抽象管理者类
    abstract class Manager
    {
   
        protected readonly string name;
        protected Manager superior;

		//构造函数里传入其管理者名字
        public Manager(string name)
        {
   
            this.name = name;
        }

        //设置上级领导的方法
        //传入一个基类，也就是自身Manager类，便于其他子类传入
        //调用这个方法是以后，其字段superior已经变成了自己的上级，调用superior这个上级的方法即可
        //superior这个上级领导字段由继承该抽象类的子类调用
        public void SetSuperior(Manager superior)
        {
   
            this.superior = superior;
        }

        //抽象方法，申请请求方法，里面放入对于管理者的业务逻辑
        public abstr