设计模式-Command
程序员文章站
2022-07-06 11:30:57
...
命令模式:将一个请求封装为一个对象,从而使你可以用不同的请求对客户进行参数化操作,实现对请求排队或记录请求日志,以及支持可撤销的操作。
模式分析:
1.命令模式的本质是对命令进行封装,将发出命令的责任和执行命令的责任分割开。
2.每一个命令都是一个操作:请求的一方发出请求,要求执行一个操作;接收的一方收到请求,并执行操作。
3.命令模式允许请求的一方和接收的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否被执行、何时被执行,以及是怎么被执行的。
4.命令模式使请求本身成为一个对象,这个对象和其他对象一样可以被存储和传递。
5.命令模式的关键在于引入了抽象命令接口,且发送者针对抽象命令接口编程,只有实现了抽象命令接口的具体命令才能与接收者相关联。
角色:
Command:定义命令的接口,声明执行的方法。
ConcreteCommand:命令接口实现对象,是“虚”的实现;通常会持有接收者,并调用接收者的功能来完成命令要执行的操作。
Receiver:接收者,真正执行命令的对象。任何类都可能成为一个接收者,只要它能够实现命令要求实现的相应功能。
Invoker:要求命令对象执行请求,通常会持有命令对象,可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方,也就是说相当于使用命令对象的入口。
Client:创建具体的命令对象,并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端,而是在组装命令对象和接收者,或许,把这个Client称为上下文会更好理解,因为真正使用命令的客户端是从Invoker来触发执行。
类结构图:
模式协作:
1. Client创建一个ConcreteCommand对象并指定他的Receiver对象
2. 某个Invoker对象存储该ConcreteCommand对象
3. 该Invoker通过调用Command对象的Execute操作来提交一个请求。若该命令是可撤销的,ConcreteCommand就在执行Execute操作之前存储当前状态以用于取消该命令
4. ConcreteCommand对象对调用它的Receiver的一些操作以执行该请求
JDK中的使用案例:
Runnable;Callable;ThreadPoolExecutor
其中:
Runnable:Command角色
具体Runnable:ConcreteCommand角色
ThreadPoolExecutor.Workerr:Receiver,只是这个接受者是个通用的,回调了Runnable的run方法。
ThreadPoolExecutor:Invoker
注意:这个使用案例并没有严格遵守 命令设计模式的结构,ConcreteCommand里没有Receiver,相反是Receiver 里放置了 Command,这是为了Worker可以通用化而做的优化。
举例:
顾客A来到餐馆点一碗面(发出请求) -> 柜台服务员记录下来(创建命令) -> 服务员把小票扔给厨房 -> 厨师C很快做好了一碗面(请求被执行)
顾客不知道将由谁来做这碗面,柜台服务员也不知道,厨师不知道是谁点了这碗面,只知道做完面就可以休息了
Command角色:
Receiver角色:
具体Command角色:
Invoker角色:
扩展阅读:
http://www.cnblogs.com/jiangu66/archive/2013/04/05/3000361.html
模式分析:
1.命令模式的本质是对命令进行封装,将发出命令的责任和执行命令的责任分割开。
2.每一个命令都是一个操作:请求的一方发出请求,要求执行一个操作;接收的一方收到请求,并执行操作。
3.命令模式允许请求的一方和接收的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否被执行、何时被执行,以及是怎么被执行的。
4.命令模式使请求本身成为一个对象,这个对象和其他对象一样可以被存储和传递。
5.命令模式的关键在于引入了抽象命令接口,且发送者针对抽象命令接口编程,只有实现了抽象命令接口的具体命令才能与接收者相关联。
角色:
Command:定义命令的接口,声明执行的方法。
ConcreteCommand:命令接口实现对象,是“虚”的实现;通常会持有接收者,并调用接收者的功能来完成命令要执行的操作。
Receiver:接收者,真正执行命令的对象。任何类都可能成为一个接收者,只要它能够实现命令要求实现的相应功能。
Invoker:要求命令对象执行请求,通常会持有命令对象,可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方,也就是说相当于使用命令对象的入口。
Client:创建具体的命令对象,并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端,而是在组装命令对象和接收者,或许,把这个Client称为上下文会更好理解,因为真正使用命令的客户端是从Invoker来触发执行。
类结构图:
模式协作:
1. Client创建一个ConcreteCommand对象并指定他的Receiver对象
2. 某个Invoker对象存储该ConcreteCommand对象
3. 该Invoker通过调用Command对象的Execute操作来提交一个请求。若该命令是可撤销的,ConcreteCommand就在执行Execute操作之前存储当前状态以用于取消该命令
4. ConcreteCommand对象对调用它的Receiver的一些操作以执行该请求
JDK中的使用案例:
Runnable;Callable;ThreadPoolExecutor
其中:
Runnable:Command角色
具体Runnable:ConcreteCommand角色
ThreadPoolExecutor.Workerr:Receiver,只是这个接受者是个通用的,回调了Runnable的run方法。
ThreadPoolExecutor:Invoker
注意:这个使用案例并没有严格遵守 命令设计模式的结构,ConcreteCommand里没有Receiver,相反是Receiver 里放置了 Command,这是为了Worker可以通用化而做的优化。
举例:
顾客A来到餐馆点一碗面(发出请求) -> 柜台服务员记录下来(创建命令) -> 服务员把小票扔给厨房 -> 厨师C很快做好了一碗面(请求被执行)
顾客不知道将由谁来做这碗面,柜台服务员也不知道,厨师不知道是谁点了这碗面,只知道做完面就可以休息了
Command角色:
public interface Command { public abstract void execute();//只需要定义一个统一的执行方法 }
Receiver角色:
public abstract class Chef { //在此定义厨师的公共属性 /** * 定义烹饪方法 */ public abstract void cook(); //在此定义其它有用的方法 } /** * @author ayqy * 定义专业做面的厨师 */ public class NoodlesChef extends Chef{ @Override public void cook() { System.out.println("做好了一碗美味的拉面"); } } /** * @author ayqy * 定义专业做饼的厨师 */ public class PieChef extends Chef{ @Override public void cook() { System.out.println("做好了一块香喷喷的大饼"); } }
具体Command角色:
public class NoodlesCommand implements Command{ private NoodlesChef chef;//专业做面的厨师 public NoodlesCommand(){ chef = new NoodlesChef(); } @Override public void execute() { chef.cook(); //调用其它需要的方法 } } public class PieCommand implements Command{ private PieChef chef;//专业做饼的厨师 public PieCommand(){ chef = new PieChef(); } @Override public void execute() { chef.cook(); //调用其它需要的方法 } }
Invoker角色:
public class Test { public static void main(String[] args) { NoodlesCommand nCmd = new NoodlesCommand(); nCmd.execute(); } }
扩展阅读:
http://www.cnblogs.com/jiangu66/archive/2013/04/05/3000361.html