总述
这样一来,我们就不用担心如何做事,我们只需要关心做什么。
封装方法调用的作用很大,我们可以保存它们用来登录,或者重用它们来实现我们代码的还原。
P213的图形象地描述了命令模式。
客户,也就是命令的发起者,有两个只能。一是他要创建命令,即CommandObject,二是他要把这个命令交给命令的接收者,即图中的invoker,这个动作是通过setCommand实现的,然后客户就没事了。
接收者负责一条一条地执行命令,至于怎么执行不是invoker所要关心的。这个命令可能在invoker执行一次以后就扔了,也可能重复使用。
那么命令的实现就交给这个receiver来完成了。
这个invoker其实除了传递命令的作用外啥也没干。
从简单命令者模式来看invoker是一个用于封装的类,它连接着client和receiver。
由于各种各样的command都是command的具体实例,所以它们都应该实现command接口。
the Command Pattern官方定义
把需求封装成一个对象,因此能让你用不同的需求、队列或者登录请求来参数化其他对象,并且支持原本无法完成的操作。
一个command对象是把一系列行为交给某一特定的receiver的。它把这一系列行为和这个receiver封装起来只留一个公有接口execute。当被调用时execute会让receiver去实现这些行为。
可以看出行为与receiver之间并不是孤立的,而是说receiver本身就具备这些行为,只不过client有权选择receiver的某些行为而已。
P219的类图很好地描述了命令模式的结构。
被封装的command和相应的receiver是绑定在一起的,这样的话就可以实现一把钥匙开一把锁的一一对应的关系。
NoCommand
命令模式中必须要处理无命令这一特殊的命令,它代表一种默认的行为,它能让客户免于无作为命令的发出行为。
这一种很重要的设计意识。
书中把它做为默认值赋给了命令对象。
undo action
撤销行为也是必需的。
因为client可能无意中发出一个并非出自本意的command,作为一个人性化的系统,你必须让system有一定的容错能力。
所以这个undo方法和execute方法是放在同一个层次中的,即,command接口中。
撤销命令是一种特殊的命令,所以它也是一个命令的实例。
P230的写法让我对撤销这一概念有了重新认识,撤销的意思是指恢复到上一个状态,而不是非工作的状态,那么完成撤销这一功能就需要保存每一个操作以便恢复。
MacroCommand
命令是多种多样的,你最好能够提供一种容器来容纳这些变化多端的命令。
使用macrocommand需要遵循如下几步:
1、你已经有了各种各样的命令,毕竟这是需求嘛,如P237所示。
2、创建的命令的载体,这里具体为数组,然后用容器把这些载体装起来,如P237所示。
3、把这个容器添加到具体的按钮的setcommand中。
4、测试。
从作者写的代码来看macrocommand实现的同一时间各种设备的同类状态的操作,比如说都是on或者都是off的状态的切换。
其实这个macrocommand的本质也是command数组,只不过它是个具体的command带有具体的execute方法而已,换句话说它是一种执行其他命令的命令。
你可以通过栈来实现连续多次撤销的功能。
队列需求
这是命令模式的另一种适用场景。
命令模式提供了一种封装计算并把它作为对象传递出去的方式。
命令对象会按照队列的方式组织在一起,一个个线程就好像包装瓶一样,每个线程获取队首的命令对象,一旦获取成功,该线程就调用该命令的execute直到结束为止。
记录需求
某些应用要求记录特定的行为动作以便在崩溃时恢复原样,命令模式可以用增加store和load的方法来提供这样的支持。
它实际上就是记录操作及其调用顺序。
在JAVA中可以通过对象序列化来实现这些方法,虽然序列化这东西往往在持久化应用中使用。
对于某写应用而言,它往往涉及到大型数据结构,所以每次变更都保存数据是不现实的,但是可以保留操作。