假定电视机/TV有方法open()、close()和changeChannel()用于打开、关闭和切换电视频道,而遥控器/Controller对TV的操作,通常使用消息传递/方法调用表达式。
图3-3 消息传递、C/S结构
命令模式则是追求一种千秋万代一统江湖的服务请求方式。
学习命令模式稍有难度,毕竟一统江湖的事情,总得有点难度。
先直接给出命令模式的例子吧。
既然有了Command,按照多态也好,难度系数为0的策略模式也罢,tv的open()演变成Command的子类OpenCommand。
OpenCommand有私有成员TV tv,而OpenCommand的exe()干什么?显然只需要一条语句tv.open()。代码自己随手写吧。
因为我们拥有依赖注入工具tool.God,(注意:在我的博客的很多的文章中,都使用了该工具,但是类名用过FromPropertyFile、IoC、God,所在包也有所变化,懒得逐一修改相关博文了。代码的意思很清楚,读者自己对应修改一下),因而代码
忽略一切细节,Controller仅依赖Command,对照的,Controller1依赖TV,和TV的现有操作/方法名。
命令模式的基本结构
①命令模式的核心,是封装普适方法exe ()的Command。通过它及其子类,将如图3-3所示的通常的服务请求中的请求发送者和接收者完全解耦,或者说将通常的C/S结构的C与S解耦。
C仅仅依赖于Command。而OpenCommand依赖于Command和S。
所以,我们常常说Command采用了命令模式。或许应该说 以Command同志为核心的命令模式?
②依赖于Command的各种类(不包括其子类),在《设计模式》中称为调用者(Invoker),它们是命令的发出者。借助反射机制或依赖注入模式或依赖注入工具类tool.God,调用者可以发出Command的各种子类封装的命令,而且不需要知道最终调用的是什么方法名、不需要知道最终谁执行。
如果调用者突发奇想地发出(需要)新的命令,可以编写Command的新子类以及执行者。
在配置文件中添加eat =method.command.EatCommand
则修改Controller的"open",即c1 =(Command)God.create("eat");就ok。《设计模式》中,给命令模式(Command Pattern)的定义/意图比较繁琐。正如刀可以砍人,你把刀玩出花样来――来个回马刀都可以,刀的基本作用还是砍人。
我的定义是:以封装普适方法的命令类层次为桥梁,将通常C/S结构的C与S解耦。
既然命令模式使得C仅仅依赖于Command,它不知道S为何物,也不知道S的接口,所以,
C下达的一系列命令,你可以组合成一个队列、可以组合成一个批命令;也可以反之,将C下达的一个命令分解成若干具体的命令;
对于命令执行前后的变化加以监控,你可以实现undo或redo;如果命令只是改变一个页面的颜色,你很容易undo/取消操作;如果命令导致手榴弹炸了一个房屋,omg,你undo就很麻烦。
你可以玩出其他花样。比如C下达的一个命令open,对于接收者为TV,就打开电视;如果配置的接收者为一个连长,他就打开/攻占一座城门。
你可以玩出更多的花样……
续 返回目录