命令模式-将请求封装成对象
目录
公号:码农充电站pro
本篇来介绍命令模式(Command Design Pattern),它将“请求”封装成对象,从而将“请求”的创建者与“请求”的执行者解耦。
1,一次购物流程
相信大家都在网上买过东西,我们以淘宝为例来介绍命令模式。
我们假设这样一个简单的场景:
- 淘宝网有很多商店,商店售卖各种各样的商品,顾客购买商品需要先在淘宝下订单。
- 一位顾客想在淘宝购买一部华为手机,他下了一个订单:“一部华为手机”。
- 淘宝网将该订单发送到华为商店。
- 华为商店将华为手机寄给了顾客。
在这个过程中,淘宝网并不关心每家商店的具体情况,它只知道每家商店都能完成它所派发的订单。
那么,我们怎样为这个场景建模呢?
2,模拟购物流程
从上面购物流程中,我们能看出来,连接顾客,淘宝网与商店的中间桥梁是订单:
- 顾客在淘宝网生成一个订单。
- 淘宝网将订单发给具体商店。
- 商店将商品寄给顾客以完成订单。
首先,我们需要定义一个 Order
接口:
interface Order {
void execute();
}
Order
接口中只有一个 execute
方法,需要派生类来实现。
然后定义一个华为商店:
abstract class Shops {
protected String shopName;
protected abstract String sell();
}
class HuaWeiShop extends Shops {
public HuaWeiShop() {
this.shopName = "HUAWEI";
}
public String sell() {
return "HuaWei Phone";
}
}
上面代码中,Shops
是一个抽象类,表示商店,商店可以销售商品。HuaWeiShop
类继承了 Shops
接口,实现了 sell
方法。
然后定义一个 GoodsOrder
类,它继承了 Order
接口,并实现了 execute
方法:
class GoodsOrder implements Order {
private Shops shop;
public GoodsOrder(Shops shop) {
this.shop = shop;
}
public void execute() {
String goods = shop.sell();
System.out.println(goods);
}
}
然后定义 Client
类,用于生成订单:
class Client {
public Order createOrder() {
Shops phone = new HuaWeiShop();
Order phoneOrder = new GoodsOrder(phone);
return phoneOrder;
}
}
下面定义淘宝网,它可以接收订单和处理订单:
class Taobao {
private Order order;
public void receiveOrder(Order order) {
this.order = order;
}
// 处理订单
public void handleOrder() {
order.execute();
}
}
最后来测试代码:
Client c = new Client();
Order order = c.createOrder(); // 顾客生成订单
Taobao t = new Taobao();
t.receiveOrder(order); // 淘宝接收订单
t.handleOrder(); // 淘宝处理订单
输出如下:
HuaWei Phone
输出表示顾客成功买到了手机。
我们画出上面代码的类图,如下:
我将完整的命令模式代码放在了这里,供大家参考。
3,命令模式
实际上,上面代码的实现方式就是命令模式。
命令模式将请求(命令)封装为一个对象,这样可以将不同请求注入到其他对象,并且能够支持请求(命令)的排队执行、记录日志、撤销等功能。
命令模式中包含以下几个组件(并把组件类比到上面的购物场景中):
- Invoker:请求的调用者,相当于 Taobao。
- Command:一个抽象接口,定义了所有具体请求必须实现的方法,相当于 Order。
- ConcreteCommand:一个具体的请求,相当于 GoodsOrder。
- Receiver:请求的接收者,用于真正的执行请求,相当于 HuaWeiShop。
- Client:请求的创建者。
命令模式的类图如下(与上面购物代码的类图一致):
上图的 Command 接口中有一个 undo
方法,它是 execute
方法的反操作,用于实现撤销功能。
命令模式通过将请求封装成对象,将请求的创建者,请求的调用者和请求的执行者,这三者之间彻底解耦:
- Client 只负责请求的创建,而不关心请求何时何地被真正的执行。
- Invoker 只负责调用请求,而不关心请求是谁创建的,也不关心请求的真正执行者是谁。
- Invoker 也可以将一个请求抛弃掉,不去调用它 。
- Receiver 只负责执行请求,而不关心请求是谁创建的,也不关心请求是被谁调用的。
4,请求服务
请求服务是一种由客户端发出请求,然后由服务端去处理的一种程序架构,不同的客户端之间互不干扰。
我们上面模拟的购物程序可以说使用的就是这种架构,如下:
比如 Redis Server 处理 Client 命令的方式使用的就是这种架构。
5,请求队列
请求被封装成对象后,可将其放在请求队列中,然后由工作线程将其取出,再执行。
这种架构也相当于一个生产者-消费者架构。
6,请求日志
请求被封装成对象后,也可以将其记录在日志中。如果服务意外崩溃,服务重启后就可以使用请求日志,将服务恢复到崩溃之前的状态。
比如 Redis 的 AOF 持久化使用的就是这种方式。
7,总结
命令模式将请求封装成对象,有两个优点:
- 使得请求的创建者与请求的调用/执行者解耦。
- 使得请求可以轻松的被传递和存储。
命令模式的这些优点,使得我们可以实现请求的排队执行、记录日志等功能。
(本节完。)
推荐阅读:
欢迎关注作者公众号,获取更多技术干货。
文章作者 @码农加油站
上次更改 2020-12-30