定 义:将一个请求封装成一个对象,从而让你使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和恢
复功能
优 点:
1、类间解耦,调用者角色与接受者角色之间没有任何依赖关系,调用者实现功能时只需调用command抽象类的execute方法即可,
不用管是具体哪个接受者执行
2、可扩展性,command可以随意扩展
缺 点:如果命令太多,会导致Invoke比较大
概述
在软件系统中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合,比如要对行为进行“记录、撤销/重做、事务”等处理,这种无法抵御变化的紧耦合是不合适的。在这种情况下,如何将“行为请求者”与“行为实现者”解耦?将一组行为抽象为对象,可以实现二者之间的松耦合[李建忠]。这就是本文要说的Command模式。
先来看看这个定义的类图实现:Command表示命令的抽象类,而ConcreteCommand则表示具体命令,而Invoke则是接收命令,并执行命令的地方,并且命令在这个地方我们都是知道这个命令的。 首先来看一个项目开发的实例,项目小组由需求小组,有美工小组,有编码小组,并且有项目负责人,在一个公司进行软件开发,软件需求是不断的变动的,这个公司为了避免自己要一个一个的去告诉美工我要修改界面,告诉编码小组什么地方要有修改,这个时候,需求公司与项目经理定义一套命令规则,我有需求只要直接告诉项目经理,而项目经理根据需求公司的需求来下达命令给各个分公司,这样,双方都得到了解脱,这些命令本来是类之间传递的一个方法,现在将其抽象出来,作为一个类来处理,简化了整个流程。先来看设计好的UML图如下所示:
有了以上设计以后,命令书面化,一切都有效率起来了。再来看看文档管理中的删除,添加,恢复文档功能,这些都是用户对文档发出的命令,为了确保客户的简化,不需要他制定是谁来处理这件事情,那么有如下设计: