【Java设计模式】行为型设计模式-委派模式(十七)

委派模式

  • 委派模式是将具体由调用者去实现的功能将其委托交付给一个或多个中间者进行处理,处理完成后又回复给调用者的模式。

进一步阐述:

  • 我们可以理解成上级分配任务到具体的员工,比如说一个大老板手下有上千个员工,平常端茶递水的活肯定不是自己干。一般口渴了就会跟下面经理说:小张啊 我口渴了给我倒杯茶!
  • 然后张经理面带微笑着回答:好的老板,这就给您倒茶。然后张经理跟下面的员工说:小刘啊,去倒杯茶过来快点哟!
  • 一会小刘把茶端过来递给张经理,张经理屁颠屁颠地把茶送到老板面前说:您要的茶来了,有点热您注意别烫着啊。
  • 这整个流程就是委派模式,老板将倒茶任务委派给张经理,张经理再将倒茶任务委派给小刘。

委派模式包含三种角色:

  • AbstractTask (抽象任务角色):是一个抽象类或者接口,含有需要处理的数据逻辑的方法,表示一个需要被执行的任务。
  • Delegater(委派者):实现或者继承了抽象任务角色,持有一个抽象任务角色(即被委派者)的引用并提供一个方法将任务委派给具体任务角色。
  • ConcreteTask(具体任务角色):实现或者继承了抽象任务角色,也是被委派者,负责具体去执行分派的任务的逻辑。

案例:上级分配经理去倒水,经理再委派给普通员工去倒水为例。其中员工Employee接口就是抽象任务角色,经理Manager类就是委派者,普通员工OrdinaryEmployee类就是具体任务角色。

UML类图:

客户端Client类:

java 复制代码
/**
 * 使用委派模式的客户端
 */
public class Client {
​
    public static void main(String[] args) {
        Boss boss = new Boss();
        boss.handOverSomething();
    }
}

老板Boss类:

java 复制代码
/**
 * 老板类
 */
public class Boss {
​
    /**
     * 交代经理去做某事
     */
    public void handOverSomething() {
        Manager mng = new Manager(new OrdinaryEmployee());
        mng.doSomething();
    }
}

员工Employee接口:

java 复制代码
/**
 * 员工接口(抽象任务角色)
 */
public interface Employee {
​
    /**
     * 做某事
     */
    void doSomething();
}

经理Manager类:

java 复制代码
/**
 * 经理类(委派者角色)
 */
public class Manager implements Employee {
​
    private Employee employee;
​
    public Manager(Employee employee) {
        this.employee = employee;
    }
​
    /**
     * 做某事
     */
    @Override
    public void doSomething() {
        employee.doSomething();
    }
}

普通员工OrdinaryEmployee类:

java 复制代码
/**
 * 普通员工类(具体任务角色也是被委派者)
 */
public class OrdinaryEmployee implements Employee {
​
    /**
     * 做倒茶水这件事
     */
    @Override
    public void doSomething() {
        System.out.println("您的茶来了,我刚倒的茶有点热您注意别烫着啊!");
    }
}

总结:

  • 委派的核心:就是对任务进行分发、调度、派遣。
  • 委派模式和代理模式的区别:代理模式注重的是过程,委派模式注重的是结果。
  • 委派模式和策略模式的区别:策略模式注重是可扩展性(外部扩展),委派模式注重内部的灵活和复用。
  • 将具体的任务和发布这个任务的调用者中间加上了一个缓冲的相当于中介者一样,使得逻辑的职能分工更加细化和明确,更好的遵守了单一职能原则。
  • 在中间的委派者角色中关联了具体的任务(即被委派者),这样就遵守合成复用原则。

典型运用场景举例: 电商的库存系统中当卖出一件商品或者是商品的数量经过商品管理服务进行修改后,不是直接去调用库存管理服务执行减库存的逻辑,而是委派给消息中间件去做,然后消息中间件又将减库存的任务委派给相关的库存服务执行。

相关推荐
高频因子挖掘机1 小时前
实时行情为什么不应该逐只股票请求?批量查询与标的池管理实践
后端·github·api
程序猿DD6 小时前
OctaFuse Gateway 2.15.0:MCP 聚合、向量 Embeddings 与官方目录同步
后端·agent
蛋蛋的就会顺顺的8 小时前
hot100 p0——栈,贪心算法,动态规划
java·前端·javascript·算法·leetcode·力扣
余槐i8 小时前
PostgreSQL 函数索引报错 must be immutable:3种绕法与代价
数据库·后端·sql·postgresql·性能优化
需要8269 小时前
Spring Bean 生命周期:从实例化到销毁的完整钩子
java·后端·spring
小 黄 鸡9 小时前
HashMap 面试必会知识点详解(JDK 8)
java·面试·职场和发展
凤山老林10 小时前
Spring Boot 接入国密 SM2/SM3/SM4 的一些实践记录
spring boot·后端·python
伯恩bourne11 小时前
Spring Boot Bean 注册的两种方式:@Component 家族 vs @Configuration + @Bean
java·spring boot·后端
张彦峰ZYF11 小时前
停顿短不等于延迟低:G1、ZGC 与低延迟服务的目标分野、代价账本与选型标定
后端·回收暂停、应用停止总时长·到达安全点、分配停滞·屏障吃吞吐、并发线程吃核心·并发窗口吃堆余量·分区式靠挑回收集兑现目标·染色指针式不支持压缩引用
silvamux_11 小时前
curl 测试 OpenAI 兼容 API 的完整流程
java·人工智能·缓存·ai·oneapi