定义: 将一个请求封装成一个对象, 从而让你使用不同的请求将客户端参数化, 对请求排队或者记录请求日志, 可以提供命令的撤销和恢复功能
通俗的说, 就是当有不同的请求时, 将每一种请求都封装成一个对象, 不同的请求调用不同的执行者来执行
命令模式的通用类图如下:
其中各部分如下:
接收者代码:
为什么 receiver 是一个抽象类呢? 因为接收者可以有多个, 有多个就需要定义一个所有特性的抽象集合.
命令角色是命令模式的核心, 其抽象的命令类代码如下:
根据环境的需求,具体的命令类也可以有多个, 代码如下:
在每个命令类中, 通过构造函数定义了该命令是针对哪一个接收者发出的, 定义一个命令接收的主题.
调用者非常简单, 仅实现命令的传递, 代码如下;
那么,如何调用呢? 场景类代码如下:
至此, 一个简单的命令模式完成
命令模式的优点
命令模式的缺点
command的子类, 如果有n个命令, 问题就出来了, command 的子类就是n个了, 这个类膨胀的非常大
命令模式的使用场景
只要认为是命令的地方就可以采用命令模式, 例如: 在gui开发中, 一个按钮的点击是一个命令,可以采用命令模式; 模拟dos命令的时候, 当然也要采用命令模式
在上面的代码中, receiver 暴露给了 client, 这样其实并不好, 命令模式的receiver在实际应用中一般都会被封装掉,每一个命令是对一个或多个receiver的封装, 我们可以在项目中通过有意义的类名或命令名处理命令角色和接收者角色的耦合关系,减少高层模块对低层模块的依赖关系, 提高系统的整体稳定性
修改后的代码如下:
实现了对 接收者的封装, 每个命令完成单一的职责, 而不是根据接收者的不同完成不同的职责, 在高层模块的调用时就不用考虑接收者是谁的问题. 场景类代码如下:
高层模块直接下达命令即可, 完美!!
可以关注一下鄙人的公众号, 谢谢各位了!
如对本文有疑问， 点击进行留言回复！！
我要评论
网友评论