
设计模式-命令模式
命令模式把一个请求或者操作封装到一个对象中。命令模式允许系统使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和恢复功能。
GitHub地址: https://github.com/UniqueDong/zero-design-stu 中的 headfirst 包下代码。
概述
命令模式是对命令的封装。命令模式把发出命令的责任和执行命令的责任分割开,委派给不同的对象。
每一个命令都是一个操作:请求的一方发出请求要求执行一个操作;接收的一方收到请求,并执行操作。命令模式允许请求的一方和接收的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否被执行、何时被执行,以及是怎么被执行的。
命令允许请求的一方和接收请求的一方能够独立演化,从而具有以下的优点:
(1)命令模式使新的命令很容易地被加入到系统里。
(2)允许接收请求的一方决定是否要否决请求。
(3)能较容易地设计一个命令队列。
(4)可以容易地实现对请求的撤销和恢复。
(5)在需要的情况下,可以较容易地将命令记入日志。
角色
● 客户端(Client)角色: 创建一个 ConcreteCommand,并设置其接受者。
● 命令(Command)角色: 为所有的命令申明一个接口。调用命令对象的 execute 方法就可以让接受者执行相关的动作,同事接口还具备一个 undo() 撤回方法。
● 具体命令(ConcreteCommand)角色: 定义一个接收者和行为之间的弱耦合;实现execute()方法,负责调用接收者的相应操作。execute()方法通常叫做执行方法。调用者只需要调用 execute 方法就可以发出请求,然后由 ConcreteCommand 调用接受者的一个或者多个动作。
● 调用者(Invoker)角色: 调用者持有一个命令对象,提供一个触发方法调用命令对象的 execute 方法,将命令执行。
● 接收者(Receiver)角色: 负责具体实施和执行一个请求。任何一个类都可以成为接收者,实施和执行请求的方法叫做行动方法。
执行流程
1.客户端创建一个命令对象。
2.客户端在调用者对象上调用 setCommand 方法。
3.在未来合适的时间点,调用者调用命令对象的 execute 方法。
4.命令通过调用者委托到对应的接受者执行。完成任务。
场景模拟
一个全能遥控器 6个可编程插槽(每个可以指定一个不同的家电装置),用来控制家电(电视、空调、冰箱、音响)。每个插槽有对应的 [开] 和 [关] 按钮。同时还具备一个整体一键撤回按钮。撤回需求是这样的,比如电灯是关的,然后按下开启按钮电灯就开了。现在假如按下撤销按钮,那么上一个动作将会翻转。在这里,电灯将会关闭。
插槽连接对应的家电,开关是对应的指令。每个家电对应两个指令,分别是 【开】和【关】按键。
许多家电都有 on() 和 off() 方法,除此之外还有一些 setVolumn()、setTV()、setTemperature() 方法。 我们总不能 写 if slot1 == Light then light.on()。
代码实现
命令接受者角色
首先我们拥有很多家电。他们其实就是不同命令的接受者执行。
◆ 灯
◆ 音响
命令角色
首先让所有的命令对象实现该接口,分别有命令执行与撤回
具体命令角色
◆ 定义开灯命令,实现 execute 。持有 命令接受者 灯的引用,从而当调用者调用 execute 将委托给对应的 灯执行开灯操作。
◆ 定义关灯命令
◆ 定义打开音响命令
◆ 定义关闭音响命令
剩下的打开电视机、关闭电视机、打开空调、关闭空调的就不一一写了。都是一样的模板套路。具体代码可以查阅 GitHub地址: https://github.com/UniqueDong/zero-design-stu 中的 headfirst 包下代码。
调用者角色
其实就是我们的遥控器。
客户端角色
获取遥控器,并且拿到灯、空调等命令接受者。分别创建对应的 【开】,【关】指令。 链接到对应的插槽。当按下按钮的时候触发指定的指令。
测试结果
总结
使用场景:
- 工作队列:在某一端添加指令,只要是实现命令模式的对象都可以放到队列里。另外一端是线程。线程进项下面的工作:从队列取出一个命令,然后调用execute 方法,调用完后将该命令丢弃,再继续取下一个命令。
- 线程池。
文章转载自公众号:码哥字节
