命令模式的困惑
我还是看GOF的那本 < <设计模式> > , 看到命令模式了, 在P157遇到这么一句:
7.协作
.Client创建一个Concretetecommand对象并指定它的Receiver对象.
这个就郁闷了, 为什么Client还要为命令指定Receiver对象呢, 如果Client知道命令接受者是谁, 干嘛不直接调用Receiver.action()完成命令呢?
而且在P155 动机 的第一句也说了: 并不知道关于被请求的操作或接收者的任何信息.
[解决办法]
我来聊聊自己的看法.
我觉得确定哪部分是稳定部分是这个问题的关键. 也就是说, 要分离出哪部分是写好以后, 在今后的维护中不变化, 不新增; 而哪部分是需要扩展的.
在这张图上, 我觉得Invoker, Command是不变化的. 有可能它是框架的一部分, 也有可能是你的高层模块. 而Client, Receiver, ConcreteCommand是需要在扩展的, 对于Client甚至是需要变化的.
我对 Client, Receiver, ConcreteCommand 的理解是, 从某种意义, 就是要促成满足 Commnad 的接口需求, 使得原先的框架能够继续下去.
希望对你有帮助. 希望进一步深入讨论.
[解决办法]
Alan Shalloway
[解决办法]
LZ的理解误区在于：你只是在看模式，没有对模式的适用进行考虑。
Boss(Invoker)
Work(Command)
Coding(ConcreteWork)
Evection(ConcreteWork)
Employee(Receiver)
Company(Client)
Boss在连让Employee该做什么Work都不知道的时候，又怎么会知道Work该由哪个Employee做呢？
当Company决定让Employee中的Coder进行Coding的时候，Boss就会命令Coder进行Coding。
显然Employee无权决定在何时执行何种action，如果让Receiver直接action，不就乱套了吗？
