命令模式
命令模式属于行为模式。命令模式将请求封装成对象,以便使用不同的请求、队列或者日志来参数化其他对象,命令模式也支持可撤销的操作。
优点:
① 命令模式把方法调用封装起来,命令模式可将“动作请求者”从“动作执行者”对象中解耦,请求者发送请求,执行者接收请求执行相应动作,因为命令模式解耦,请求者无需知道执行者任何接口。
② 命令模式可以支持撤销,做法是实现一个undo()方法来回到execute()方法被执行前的状态。
不少命令模式的代码都是针对图形界面的,它实际就是菜单命令,我们在一个下拉菜单选择一个命令时,然后会执行一些动作.
将这些命令封装成在一个类中,然后用户(调用者)再对这个类进行操作,这就是Command模式,换句话说,本来用户(调用者)是直接调用这些命令的,如菜单上打开文档(调用者),就直接指向打开文档的代码,使用Command模式,就是在这两者之间增加一个中间者,将这种直接关系拗断,同时两者之间都隔离,基本没有关系了.
也可以这么理解:命令模式采用“命令对象”,一个命令对象通过在特定的接受者上绑定一组动作来封装一个请求,命令对象将动作和接受者包进对象中,这个对象只暴露出一个execute()方法,当次方法被调用时,接受者就会进行这些动作。 利用命令对象,把请求(例如打开电灯)封装成一个特定的对象(例如客厅电灯对象),所以,如果对每个按钮都有存储一个命令对象,那么当按钮被按下的时候,就可以请命令对象做相应的工作,遥控器并不要知道工作内容是什么,只要有个命令对象和正确的对象进行沟通,把事情做好就可以了,遥控器和电灯对象解耦了。。
显然这样做的好处是符合封装的特性,降低耦合度,Command是将对行为进行封装的典型模式,Factory是将创建进行封装的模式,
从命令模式,我也发现设计模式一个"通病":好象喜欢将简单的问题复杂化, 喜欢在不同类中增加第三者,当然这样做有利于代码的健壮性 可维护性 还有复用性.