写作思考：命令模式(5.2)

命令模式是一个学习起来相对较难的模式。难点在于Invoker为什么会想到不管不顾地依赖Command，而后者封装一个普适方法exe ()。另一方面，在于GoF对于命令模式意图的描述夸大其词，使得命令模式与策略模式/行为参数化混淆。

命令模式(5.2)放在哪里讲，一直定不下来。可以放在第二章行为参数化中，现在放在《第四章策略模式的演变》中，命令模式不是演变，是对立/对比。还有个问题：适配器应该在命令模式之前讲，怎么办？搞一个倒叙？

内容方面：

1.傻乎乎的幸福  先给出命令模式合理使用的场景，Invoker不知道应该依赖谁！以此作为整个命令模式讨论的基础。【很多人认为命令模式的优点，是完成消息发出者与执行者(Invoker/ Receiver)之间的解耦，并认为采用命令模式使得软件有更松散的耦合。从结果上看有一点道理，但事实上，使用命令模式不是希望Invoker和Receiver离婚，Invoker只有10岁，他完全就不知道它老婆将会是谁。命令模式解耦？耦都没有，咋解。】

2. 命令模式与行为参数化 这一节喷GoF，GoF的错误在于对命令模式的定义：『将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式的别名为动作(Action)模式或事务(Transaction)模式』。这是一种扩大命令模式的外延的做法。行为参数化中Condition、INext、IItem等类层次都符合——甚至比Command类层次更加符合将“一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化”。

3.万能的适配目标？ 解决学习难点。Invoker为什么会想到不管不顾地依赖Command，我关于命令模式的定义：

★Command模式：Invoker不知道应该依赖谁，因此将普适方法exe ()作为适配目标。Command模式是适配器模式的特例。

4.调用者/Invoker与Client的关系问题  这一节不知道要不要加。简单地例子中，Client是一个Demo，依赖Invoker；GoF类图中，Client不依赖Invoker。

5. 对请求排队或者记录请求日志，以及支持可撤销的操作    我准备不加理会。