设计模式 ☞ 行为型之命令模式

2021-01-13 14:58:13 浏览数 (1)

1.1 简介

1.1.1 概述

  命令(Command)模式的定义如下:将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通,这样方便将命令对象进行储存、传递、调用、增加与管理。比如看电视时,我们只需要轻轻一按遥控器就能完成频道的切换,这就是命令模式,将换台请求和换台处理完全解耦了。电视机遥控器(命令发送者)通过按钮(具体命令)来遥控电视机(命令接收者)。

1.1.2 优缺点

优点:  ① 通过引入中间件(抽象接口)降低系统的耦合度。  ② 扩展性良好,增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类,且满足“开闭原则”。  ③ 可以实现宏命令。命令模式可以与组合模式结合,将多个命令装配成一个组合命令,即宏命令。  ④ 方便实现 Undo 和 Redo 操作。命令模式可以与后面介绍的备忘录模式结合,实现命令的撤销与恢复。  ⑤ 可以在现有命令的基础上,增加额外功能。比如日志记录,结合装饰器模式会更加灵活。

缺点:  ① 可能产生大量具体的命令类。因为每一个具体操作都需要设计一个具体命令类,这会增加系统的复杂性。  ② 命令模式的结果其实就是接收方的执行结果,但是为了以命令的形式进行架构、解耦请求与实现,引入了额外类型结构(引入了请求方与抽象命令接口),增加了理解上的困难。不过这也是设计模式的通病,抽象必然会额外增加类的数量,代码抽离肯定比代码聚合更加难理解。

1.2 案例

  客户去饭店吃饭的时候,点蒸羊羔,蒸熊掌,蒸鹿尾儿,烧花鸭,烧雏鸡儿。服务员会一一记录在单子上,然后通知后厨开始制作,如果中途想要更改,服务员也会在单子上做相应的操作并通知后厨。我们不用管服务员是怎么干的,我们只管向服务员标明诉求,我们得到结果就行了。如下图所示,客户就是客户端(Client),服务员就是发送者(Invoker),单子就是命令(Command),后厨就是接收者(Receiver)。

0 人点赞