设计模式之命令模式
2013-07-02 22:47
183 查看
先看简单的命令模式代码实现:
/**
* 客户端调用类
* @author 光腚
*
*/
public class Client {
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
FunctioinButton button = new FunctioinButton("功能设置键");
/**
* 此处设置具体的命令类,具体的命令类通常设置到XML文件里面,这样需要更改
* 具体的命令接受类的时候只需要更改配置文件即可,这样方可符合开闭原则
*/
Command command = new HelpCommand();
button.setCommand(command);
button.onclick();
}
}
/**
* 窗口类 具体的命令类
* @author 光腚
*
*/
上述模式应用背景是,有一个按钮,这个按钮可以配置不同的事件处理,如打开文档,缩小窗口,我们实现的目的是符合开闭原则,并且能不断修改命令的处理类,依据我们以前的设计模式经验,不同对象之间的更改该常需要引入XML文件,然后通过配置文件的方式来决定更改的类对象,所以,问题来了,如果我们把具体的命令接受者(打开文档类,窗口缩小类)让他们实现统一抽象类,然后按钮类针对这个抽象类编程,如果更改不同的命令接受者,那么我们直接更改XML文件不就可以了嘛,理论上是可以的,但是这里我们必须要注意一下命令模式和桥接模式区别,事实上对于文档显示类和窗口缩小类他们并没有彼此相互的联系,他们各自执行的方法也就不相同,因此很难依据依赖倒转原则来对他们进行抽象,因此,我们这种设想方式就不能执行了。也正是在这样一种背景下,引入了命令模式。
命令模式的核心就在于引入了命令类,一个命令类和一个具体的命令接受者类关联,也就有多个命令类,然后我们针对命令类抽象层,每个命令类都实现统一的方法如上面的execute(),然后让命令发送者针对命令类来调用,这样,通过引入命令类,我们就可以解决以上问题了,所以我常把命令模式理解为在外观模式或者桥接模式外面又封了一层,在这一层关联具体的实现,调用者调用封装层,因此,由于封装层充当了命令的角色,因此,这样的一种设计模式叫做命令模式。
/**
* 客户端调用类
* @author 光腚
*
*/
public class Client {
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
FunctioinButton button = new FunctioinButton("功能设置键");
/**
* 此处设置具体的命令类,具体的命令类通常设置到XML文件里面,这样需要更改
* 具体的命令接受类的时候只需要更改配置文件即可,这样方可符合开闭原则
*/
Command command = new HelpCommand();
button.setCommand(command);
button.onclick();
}
}
/** * 抽象命令类 * */ public abstract class Command { public abstract void execute(); }
public class FunctioinButton { private Command command; private String buttonName; public FunctioinButton(String buttonName){ this.buttonName = buttonName; } /** * 为功能键注入具体的命令类 * @param command */ public void setCommand(Command command) { this.command = command; } public void onclick(){ System.out.println("点击按钮,请求者发送请求!!!"); command.execute(); } }
/** * 帮助文档 命令类: 具体的命令类 * @author 光腚 * */ public class HelpCommand extends Command{ private HelpHandler hhobj; public HelpCommand(){ this.hhobj = new HelpHandler(); } @Override public void execute() { // TODO Auto-generated method stub hhobj.display(); } }
/** * 请求接受者 :帮助文档处理类 * @author 光腚 * */ public class HelpHandler { public void display(){ System.out.println("显示帮助文档"); } }
/** * 窗口处理类 :请求接受者 * @author 光腚 * */ public class WindowHandler { public void minize(){ System.out.println("将窗口最小化至托盘"); } }
/**
* 窗口类 具体的命令类
* @author 光腚
*
*/
public class WindowMinizeCommand extends Command{ private WindowHandler whobj; public WindowMinizeCommand(){ this.whobj = new WindowHandler(); } @Override public void execute() { // TODO Auto-generated method stub whobj.minize(); } }命令模式的本质在于引入抽象命令类,一个具体的请求处理者(如上面的文档显示类,窗口缩小类)对应一个具体的命令类,请求发送者,针对抽象命令类编程。
上述模式应用背景是,有一个按钮,这个按钮可以配置不同的事件处理,如打开文档,缩小窗口,我们实现的目的是符合开闭原则,并且能不断修改命令的处理类,依据我们以前的设计模式经验,不同对象之间的更改该常需要引入XML文件,然后通过配置文件的方式来决定更改的类对象,所以,问题来了,如果我们把具体的命令接受者(打开文档类,窗口缩小类)让他们实现统一抽象类,然后按钮类针对这个抽象类编程,如果更改不同的命令接受者,那么我们直接更改XML文件不就可以了嘛,理论上是可以的,但是这里我们必须要注意一下命令模式和桥接模式区别,事实上对于文档显示类和窗口缩小类他们并没有彼此相互的联系,他们各自执行的方法也就不相同,因此很难依据依赖倒转原则来对他们进行抽象,因此,我们这种设想方式就不能执行了。也正是在这样一种背景下,引入了命令模式。
命令模式的核心就在于引入了命令类,一个命令类和一个具体的命令接受者类关联,也就有多个命令类,然后我们针对命令类抽象层,每个命令类都实现统一的方法如上面的execute(),然后让命令发送者针对命令类来调用,这样,通过引入命令类,我们就可以解决以上问题了,所以我常把命令模式理解为在外观模式或者桥接模式外面又封了一层,在这一层关联具体的实现,调用者调用封装层,因此,由于封装层充当了命令的角色,因此,这样的一种设计模式叫做命令模式。
相关文章推荐
- 【设计模式基础】行为模式 - 4 - 命令(Command)
- 设计模式-命令模式
- 走穿java23种设计模式--14命令模式详解
- 设计模式之美:Command(命令)
- 设计模式之命令设计模式
- Java23种设计模式——命令模式
- 23种设计模式(17)java命令模式
- 设计模式学习笔记(十七)——Command命令模式
- 【学习笔记】设计模式-命令模式
- 设计模式——命令模式(Command)
- Java设计模式(九)责任链模式 命令模式
- 设计模式——命令模式
- 设计模式--命令实现C++
- 设计模式 - 命令模式(command pattern) 撤销(undo) 具体解释
- 大话设计-命令模式
- Java设计模式——命令模式(Command Pattern)
- 小话设计模式(十四)命令模式
- 设计模式C++描述----19.命令(Command)模式
- Java设计模式-命令模式
- 设计模式之七 命令模式(Command Pattern)