命令模式

             命令模式属于行为模式。命令模式将请求封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象，命令模式也支持可撤销的操作。

优点：

         ① 命令模式把方法调用封装起来，命令模式可将“动作请求者”从“动作执行者”对象中解耦，请求者发送请求，执行者接收请求执行相应动作，因为命令模式解耦，请求者无需知道执行者任何接口。

          ② 命令模式可以支持撤销，做法是实现一个undo（）方法来回到execute（）方法被执行前的状态。

 

           不少命令模式的代码都是针对图形界面的,它实际就是菜单命令,我们在一个下拉菜单选择一个命令时,然后会执行一些动作.

           将这些命令封装成在一个类中,然后用户(调用者)再对这个类进行操作,这就是Command模式,换句话说,本来用户(调用者)是直接调用这些命令的,如菜单上打开文档(调用者),就直接指向打开文档的代码,使用Command模式,就是在这两者之间增加一个中间者,将这种直接关系拗断,同时两者之间都隔离,基本没有关系了.

          也可以这么理解：命令模式采用“命令对象”，一个命令对象通过在特定的接受者上绑定一组动作来封装一个请求，命令对象将动作和接受者包进对象中，这个对象只暴露出一个execute（）方法，当次方法被调用时，接受者就会进行这些动作。    利用命令对象，把请求（例如打开电灯）封装成一个特定的对象（例如客厅电灯对象），所以，如果对每个按钮都有存储一个命令对象，那么当按钮被按下的时候，就可以请命令对象做相应的工作，遥控器并不要知道工作内容是什么，只要有个命令对象和正确的对象进行沟通，把事情做好就可以了，遥控器和电灯对象解耦了。。

           显然这样做的好处是符合封装的特性,降低耦合度,Command是将对行为进行封装的典型模式,Factory是将创建进行封装的模式,
从命令模式,我也发现设计模式一个"通病":好象喜欢将简单的问题复杂化, 喜欢在不同类中增加第三者,当然这样做有利于代码的健壮性 可维护性 还有复用性.