命令(Command)模式:又称Action模式或者Transaction模式。它属于对象的行为模式。命令模式把一个请求或者操作封装到一个对象中。命令模式允许系统使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和撤销功能。
GoF命令模式结构图如下:
命令模式是有以下角色:
抽象命令(Command)角色:声明执行操作的接口。
具体命令(ConcreteCommand)角色:将一个接收者对象绑定到一个动作上。调用接收者相应的操作,以实现Execute方法。
客户端(Client)角色:创建一个命令对象并设定它的接收者。
请求者(Invoker)角色:负责调用命令对象的执行请求;
接收者(Receiver)角色:负责具体实施和执行一个请求相关的操作。任何一个类都可以作为一个接收者。
上面模型的模拟代码如下:
- package command;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:39:48
- *描述:接收者角色
- */
- public class Receiver {
- public Receiver() {
- super();
- }
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:40:00
- *描述:行动方法
- */
- public void action(){
- System.out.println("接收者接到命令,开始行动");
- }
- }
- package command;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:36:51
- *描述:抽象命令角色
- */
- public interface Command {
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:36:40
- *描述:执行方法
- */
- public void execute();
- }
- package command;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:37:10
- *描述:具体命令角色
- */
- public class ConcreteCommand implements Command {
- private Receiver receiver;
- public ConcreteCommand(Receiver receiver) {
- super();
- this.receiver = receiver;
- }
- @Override
- public void execute() {
- receiver.action();
- }
- }
- package command;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:41:07
- *描述:
- */
- public class Invoker {
- private Command command;
- public Invoker(Command command) {
- super();
- this.command = command;
- }
- public void action(){
- command.execute();
- }
- }
- package command;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:33:51
- *描述:客户端角色
- */
- public class Client {
- /**
- *作者:alaric
- *时间:2013-8-20下午7:33:44
- *描述:
- */
- public static void main(String[] args) {
- Receiver receiver = new Receiver();
- Command command = new ConcreteCommand(receiver);
- Invoker invoker = new Invoker(command);
- invoker.action();
- }
- }
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
在讲门面模式的时候曾经提过一个例子,我们小时玩过投币的那种游戏机,一个方向操作杆,四个动作按钮,在一个操作面板上,封装了复杂的逻辑在机器内部,提供简单的操作界面,是一个门面的例子,然而每个操作发出一个命令,来控制游戏人物的运动和各种动作。方向操作杆是一个移动的命令,传入移动的方向和距离作为参数,还有出拳按键发出出拳命令,脚踢按键发出脚踢的命令,那还有组合操作命令,比如下踢腿(操作杆向下和踢脚按钮按下)。现在我们用命令模式来模拟这个场景。类的模型图如下:
如上图所示:Client相当于小时候的我们,Control相关于控制执行器,我们可以控制踢(KickCommand)、打(FistCommand)、移动(MoveCommand),这些命令的最终实现者也是接收者是游戏机(GameMachine)。
代码如下:
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-21上午7:15:53
- *描述:接收者
- */
- public class GameMachine {
- public void fist() {
- System.out.println("出拳");
- }
- public void kick() {
- System.out.println("出脚");
- }
- public void move(String direction){
- System.out.println("向"+direction+"移动");
- }
- }
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午10:20:35
- *描述:命令接口
- */
- public interface Command {
- //执行方法
- public void execute();
- //这里还可以加入撤销方法,回滚方法等
- }
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-21上午7:17:02
- *描述:拳打
- */
- public class FistCommand implements Command {
- private GameMachine machine;
- public FistCommand(GameMachine machine) {
- super();
- this.machine = machine;
- }
- @Override
- public void execute() {
- machine.fist();
- }
- }
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-21上午7:42:21
- *描述:脚踢命令
- */
- public class KickCommand implements Command {
- private GameMachine machine;
- public KickCommand(GameMachine machine) {
- super();
- this.machine = machine;
- }
- @Override
- public void execute() {
- machine.kick();
- }
- }
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-21上午7:17:02
- *描述:移动命令
- */
- public class MoveCommand implements Command {
- private GameMachine machine;
- private String direction;
- public MoveCommand(GameMachine machine,String direction) {
- super();
- this.machine = machine;
- this.direction = direction;
- }
- @Override
- public void execute() {
- machine.move(direction);
- }
- }
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-21上午7:43:14
- *描述:控制类
- */
- public class Control {
- private Command fistCommand;
- private Command kickCommand;
- private Command moveCommand;
- public Control(Command fistCommand, Command kickCommand, Command moveCommand) {
- super();
- this.fistCommand = fistCommand;
- this.kickCommand = kickCommand;
- this.moveCommand = moveCommand;
- }
- public void fist(){
- fistCommand.execute();
- }
- public void kick(){
- kickCommand.execute();
- }
- public void move(){
- moveCommand.execute();
- }
- }
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午9:26:42
- *描述:客户端角色
- */
- public class Client {
- /**
- *作者:alaric
- *时间:2013-8-20下午9:26:36
- *描述:测试
- */
- public static void main(String[] args) {
- GameMachine machine = new GameMachine();
- Command fistCommand = new FistCommand(machine);
- Command kickCommand = new KickCommand(machine);
- Command moveCommand = new MoveCommand(machine, "左");
- Control control = new Control(fistCommand, kickCommand, moveCommand);
- control.fist();
- control.kick();
- control.move();
- //其实在不同命令模式的情况下就是下面这样直接调用,
- //就会让调用者和实际命令执行者紧紧耦合在一起,还有一个好处
- //就是可以在
- //machine.fist();
- //machine.kick();
- //machine.move("左");
- }
- }
运行结果如下:
出拳
出脚
向左移动
通过上面代码可以看出,本来客户端可以直接调用接收者来执行动作的,现在在中间引入了命令,这些命令由调用者(Invoker这里是Control)来调用,从而对客户端和命令接收者解耦了,增加了命令后,使得命令除了execute方法外,可以插入很多其它动作,比如redo,undo,或者记录日志等。
<iframe id="aswift_0" style="left: 0px; position: absolute; top: 0px;" name="aswift_0" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" width="728" height="90"></iframe>
评论
11 楼 strivezsh 18 小时前
zzq19860626 写道
ljqian 写道
chenqidou 写道
原文代码:GameMachine machine = new GameMachine();
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
首先,您的这种想法在国内众多开发者中普遍存在,至少让我来做的话,我有很大的概率会选择您的做法,理由很简单,开发起来方便。
但这边讨论的是设计模式,设计模式有很多个原则,其中有一条说的是:类应该对修改关闭,对扩展开放。是什么意思和为什么要这么做,请自己google吧。您说的如果要添加一个命令的功能,只需添加一个函数而已,这点在实现上确实是如此的。但请考虑到扩展问题,每天加一个新命令就需要修改下原有的代码,如果说这代码还是由你来负责,我想依您的实力应该没什么问题,那万一这代码不再由您负责了呢,面对一大串的函数,我想没人会觉得轻松吧。当然,您可以说"反正不是我负责了,不关我的事",但如果是别人写的这一大串代码给你去修改呢,情况又会如何
这个解释够清楚了!
其实吧 是这个人 不懂得 什么 叫做 举个栗子
10 楼 zzq19860626 19 小时前
ljqian 写道
chenqidou 写道
原文代码:GameMachine machine = new GameMachine();
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
首先,您的这种想法在国内众多开发者中普遍存在,至少让我来做的话,我有很大的概率会选择您的做法,理由很简单,开发起来方便。
但这边讨论的是设计模式,设计模式有很多个原则,其中有一条说的是:类应该对修改关闭,对扩展开放。是什么意思和为什么要这么做,请自己google吧。您说的如果要添加一个命令的功能,只需添加一个函数而已,这点在实现上确实是如此的。但请考虑到扩展问题,每天加一个新命令就需要修改下原有的代码,如果说这代码还是由你来负责,我想依您的实力应该没什么问题,那万一这代码不再由您负责了呢,面对一大串的函数,我想没人会觉得轻松吧。当然,您可以说"反正不是我负责了,不关我的事",但如果是别人写的这一大串代码给你去修改呢,情况又会如何
这个解释够清楚了!
9 楼 ljqian 19 小时前
chenqidou 写道
原文代码:GameMachine machine = new GameMachine();
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
首先,您的这种想法在国内众多开发者中普遍存在,至少让我来做的话,我有很大的概率会选择您的做法,理由很简单,开发起来方便。
但这边讨论的是设计模式,设计模式有很多个原则,其中有一条说的是:类应该对修改关闭,对扩展开放。是什么意思和为什么要这么做,请自己google吧。您说的如果要添加一个命令的功能,只需添加一个函数而已,这点在实现上确实是如此的。但请考虑到扩展问题,每天加一个新命令就需要修改下原有的代码,如果说这代码还是由你来负责,我想依您的实力应该没什么问题,那万一这代码不再由您负责了呢,面对一大串的函数,我想没人会觉得轻松吧。当然,您可以说"反正不是我负责了,不关我的事",但如果是别人写的这一大串代码给你去修改呢,情况又会如何
8 楼 ifox 昨天
已經在看啦。
多謝
多謝
7 楼 zzq19860626 昨天
chenqidou 写道
原文代码:GameMachine machine = new GameMachine();
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
首先这里欢迎所有人来拍砖。每设计模式是一种思想,是前人总结的经验,但它是有使用场合的,如果我们写个test或者练习的main方法,用设计模式显得多余,。上文中,直接
//machine.fist();
//machine.kick();
//machine.move("左");
减少类,减少调用流程, 多简单;但是这里是讲设计模式,设计模式的目的是提高系统的可扩展性、可维护性。
6 楼 suneyejava 昨天
chenqidou 写道
原文代码:GameMachine machine = new GameMachine();
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
照你这么说,所有的设计模式都没任何用处了?要做大项目设计模式是必须的。
5 楼 chenqidou 昨天
原文代码:GameMachine machine = new GameMachine();
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
4 楼 zzq19860626 昨天
jayung 写道
顶,iteye有你更精彩。
谢谢围观~
3 楼 jayung 昨天
顶,iteye有你更精彩。
2 楼 zzq19860626 昨天
谷超 写道
帅气,写了这么多的设计模式的文章,有时间细细研读体会!
谢谢关注,欢迎拍砖。
1 楼 谷超 昨天
帅气,写了这么多的设计模式的文章,有时间细细研读体会!
命令(Command)模式:又称Action模式或者Transaction模式。它属于对象的行为模式。命令模式把一个请求或者操作封装到一个对象中。命令模式允许系统使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和撤销功能。
GoF命令模式结构图如下:
命令模式是有以下角色:
抽象命令(Command)角色:声明执行操作的接口。
具体命令(ConcreteCommand)角色:将一个接收者对象绑定到一个动作上。调用接收者相应的操作,以实现Execute方法。
客户端(Client)角色:创建一个命令对象并设定它的接收者。
请求者(Invoker)角色:负责调用命令对象的执行请求;
接收者(Receiver)角色:负责具体实施和执行一个请求相关的操作。任何一个类都可以作为一个接收者。
上面模型的模拟代码如下:
- package command;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:39:48
- *描述:接收者角色
- */
- public class Receiver {
- public Receiver() {
- super();
- }
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:40:00
- *描述:行动方法
- */
- public void action(){
- System.out.println("接收者接到命令,开始行动");
- }
- }
- package command;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:36:51
- *描述:抽象命令角色
- */
- public interface Command {
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:36:40
- *描述:执行方法
- */
- public void execute();
- }
- package command;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:37:10
- *描述:具体命令角色
- */
- public class ConcreteCommand implements Command {
- private Receiver receiver;
- public ConcreteCommand(Receiver receiver) {
- super();
- this.receiver = receiver;
- }
- @Override
- public void execute() {
- receiver.action();
- }
- }
- package command;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:41:07
- *描述:
- */
- public class Invoker {
- private Command command;
- public Invoker(Command command) {
- super();
- this.command = command;
- }
- public void action(){
- command.execute();
- }
- }
- package command;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午7:33:51
- *描述:客户端角色
- */
- public class Client {
- /**
- *作者:alaric
- *时间:2013-8-20下午7:33:44
- *描述:
- */
- public static void main(String[] args) {
- Receiver receiver = new Receiver();
- Command command = new ConcreteCommand(receiver);
- Invoker invoker = new Invoker(command);
- invoker.action();
- }
- }
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
在讲门面模式的时候曾经提过一个例子,我们小时玩过投币的那种游戏机,一个方向操作杆,四个动作按钮,在一个操作面板上,封装了复杂的逻辑在机器内部,提供简单的操作界面,是一个门面的例子,然而每个操作发出一个命令,来控制游戏人物的运动和各种动作。方向操作杆是一个移动的命令,传入移动的方向和距离作为参数,还有出拳按键发出出拳命令,脚踢按键发出脚踢的命令,那还有组合操作命令,比如下踢腿(操作杆向下和踢脚按钮按下)。现在我们用命令模式来模拟这个场景。类的模型图如下:
如上图所示:Client相当于小时候的我们,Control相关于控制执行器,我们可以控制踢(KickCommand)、打(FistCommand)、移动(MoveCommand),这些命令的最终实现者也是接收者是游戏机(GameMachine)。
代码如下:
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-21上午7:15:53
- *描述:接收者
- */
- public class GameMachine {
- public void fist() {
- System.out.println("出拳");
- }
- public void kick() {
- System.out.println("出脚");
- }
- public void move(String direction){
- System.out.println("向"+direction+"移动");
- }
- }
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午10:20:35
- *描述:命令接口
- */
- public interface Command {
- //执行方法
- public void execute();
- //这里还可以加入撤销方法,回滚方法等
- }
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-21上午7:17:02
- *描述:拳打
- */
- public class FistCommand implements Command {
- private GameMachine machine;
- public FistCommand(GameMachine machine) {
- super();
- this.machine = machine;
- }
- @Override
- public void execute() {
- machine.fist();
- }
- }
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-21上午7:42:21
- *描述:脚踢命令
- */
- public class KickCommand implements Command {
- private GameMachine machine;
- public KickCommand(GameMachine machine) {
- super();
- this.machine = machine;
- }
- @Override
- public void execute() {
- machine.kick();
- }
- }
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-21上午7:17:02
- *描述:移动命令
- */
- public class MoveCommand implements Command {
- private GameMachine machine;
- private String direction;
- public MoveCommand(GameMachine machine,String direction) {
- super();
- this.machine = machine;
- this.direction = direction;
- }
- @Override
- public void execute() {
- machine.move(direction);
- }
- }
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-21上午7:43:14
- *描述:控制类
- */
- public class Control {
- private Command fistCommand;
- private Command kickCommand;
- private Command moveCommand;
- public Control(Command fistCommand, Command kickCommand, Command moveCommand) {
- super();
- this.fistCommand = fistCommand;
- this.kickCommand = kickCommand;
- this.moveCommand = moveCommand;
- }
- public void fist(){
- fistCommand.execute();
- }
- public void kick(){
- kickCommand.execute();
- }
- public void move(){
- moveCommand.execute();
- }
- }
- package command.example;
- /**
- *
- *作者:alaric
- *时间:2013-8-20下午9:26:42
- *描述:客户端角色
- */
- public class Client {
- /**
- *作者:alaric
- *时间:2013-8-20下午9:26:36
- *描述:测试
- */
- public static void main(String[] args) {
- GameMachine machine = new GameMachine();
- Command fistCommand = new FistCommand(machine);
- Command kickCommand = new KickCommand(machine);
- Command moveCommand = new MoveCommand(machine, "左");
- Control control = new Control(fistCommand, kickCommand, moveCommand);
- control.fist();
- control.kick();
- control.move();
- //其实在不同命令模式的情况下就是下面这样直接调用,
- //就会让调用者和实际命令执行者紧紧耦合在一起,还有一个好处
- //就是可以在
- //machine.fist();
- //machine.kick();
- //machine.move("左");
- }
- }
运行结果如下:
出拳
出脚
向左移动
通过上面代码可以看出,本来客户端可以直接调用接收者来执行动作的,现在在中间引入了命令,这些命令由调用者(Invoker这里是Control)来调用,从而对客户端和命令接收者解耦了,增加了命令后,使得命令除了execute方法外,可以插入很多其它动作,比如redo,undo,或者记录日志等。
<iframe id="aswift_0" style="left: 0px; position: absolute; top: 0px;" name="aswift_0" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" width="728" height="90"></iframe>
评论
11 楼 strivezsh 18 小时前
zzq19860626 写道
ljqian 写道
chenqidou 写道
原文代码:GameMachine machine = new GameMachine();
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
首先,您的这种想法在国内众多开发者中普遍存在,至少让我来做的话,我有很大的概率会选择您的做法,理由很简单,开发起来方便。
但这边讨论的是设计模式,设计模式有很多个原则,其中有一条说的是:类应该对修改关闭,对扩展开放。是什么意思和为什么要这么做,请自己google吧。您说的如果要添加一个命令的功能,只需添加一个函数而已,这点在实现上确实是如此的。但请考虑到扩展问题,每天加一个新命令就需要修改下原有的代码,如果说这代码还是由你来负责,我想依您的实力应该没什么问题,那万一这代码不再由您负责了呢,面对一大串的函数,我想没人会觉得轻松吧。当然,您可以说"反正不是我负责了,不关我的事",但如果是别人写的这一大串代码给你去修改呢,情况又会如何
这个解释够清楚了!
其实吧 是这个人 不懂得 什么 叫做 举个栗子
10 楼 zzq19860626 19 小时前
ljqian 写道
chenqidou 写道
原文代码:GameMachine machine = new GameMachine();
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
首先,您的这种想法在国内众多开发者中普遍存在,至少让我来做的话,我有很大的概率会选择您的做法,理由很简单,开发起来方便。
但这边讨论的是设计模式,设计模式有很多个原则,其中有一条说的是:类应该对修改关闭,对扩展开放。是什么意思和为什么要这么做,请自己google吧。您说的如果要添加一个命令的功能,只需添加一个函数而已,这点在实现上确实是如此的。但请考虑到扩展问题,每天加一个新命令就需要修改下原有的代码,如果说这代码还是由你来负责,我想依您的实力应该没什么问题,那万一这代码不再由您负责了呢,面对一大串的函数,我想没人会觉得轻松吧。当然,您可以说"反正不是我负责了,不关我的事",但如果是别人写的这一大串代码给你去修改呢,情况又会如何
这个解释够清楚了!
9 楼 ljqian 19 小时前
chenqidou 写道
原文代码:GameMachine machine = new GameMachine();
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
首先,您的这种想法在国内众多开发者中普遍存在,至少让我来做的话,我有很大的概率会选择您的做法,理由很简单,开发起来方便。
但这边讨论的是设计模式,设计模式有很多个原则,其中有一条说的是:类应该对修改关闭,对扩展开放。是什么意思和为什么要这么做,请自己google吧。您说的如果要添加一个命令的功能,只需添加一个函数而已,这点在实现上确实是如此的。但请考虑到扩展问题,每天加一个新命令就需要修改下原有的代码,如果说这代码还是由你来负责,我想依您的实力应该没什么问题,那万一这代码不再由您负责了呢,面对一大串的函数,我想没人会觉得轻松吧。当然,您可以说"反正不是我负责了,不关我的事",但如果是别人写的这一大串代码给你去修改呢,情况又会如何
8 楼 ifox 昨天
已經在看啦。
多謝
多謝
7 楼 zzq19860626 昨天
chenqidou 写道
原文代码:GameMachine machine = new GameMachine();
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
首先这里欢迎所有人来拍砖。每设计模式是一种思想,是前人总结的经验,但它是有使用场合的,如果我们写个test或者练习的main方法,用设计模式显得多余,。上文中,直接
//machine.fist();
//machine.kick();
//machine.move("左");
减少类,减少调用流程, 多简单;但是这里是讲设计模式,设计模式的目的是提高系统的可扩展性、可维护性。
6 楼 suneyejava 昨天
chenqidou 写道
原文代码:GameMachine machine = new GameMachine();
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
照你这么说,所有的设计模式都没任何用处了?要做大项目设计模式是必须的。
5 楼 chenqidou 昨天
原文代码:GameMachine machine = new GameMachine();
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
18. Command fistCommand = new FistCommand(machine);
19. Command kickCommand = new KickCommand(machine);
20. Command moveCommand = new MoveCommand(machine, "左");
21.
22. Control control = new Control(fistCommand, kickCommand, moveCommand);
23. control.fist();
24. control.kick();
25. control.move();
本人分析:
首先,把GameMachine的功能进行分解成一个一个继承Command的类;让后有把所有类重新组装成Control类,然后调用control的函数;这样的做法不是浪费资源,浪费人力,浪费时间么?
原文内容:
1、命令模式使新的命令在不改变现有结构代码的情况下很容易被加入到系统里;
2、允许接收请求的一方决定是否否决请求;
3、能较容易地设计一个命令队列;
4、可以容易地实现对请求的Undo和Redo操作;
5、在需要的情况下以较容易地将命令记入日志。
本人论点:针对第一个优点,我们可以做个假设,如果要添加一个命令的功能,不用设计模式,只要在GameMachine里面添加个函数而已,然后直接调用;而如果用原文论述的设计模式,首先在GameMachine中,添加该命令函数,然后加个类继承command,并调用GameMachine中的命令方法,最后在control继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
4 楼 zzq19860626 昨天
jayung 写道
顶,iteye有你更精彩。
谢谢围观~
3 楼 jayung 昨天
顶,iteye有你更精彩。
2 楼 zzq19860626 昨天
谷超 写道
帅气,写了这么多的设计模式的文章,有时间细细研读体会!
谢谢关注,欢迎拍砖。
1 楼 谷超 昨天
帅气,写了这么多的设计模式的文章,有时间细细研读体会!
相关推荐
本资料“《java设计模式》课后习题模拟试题解答——刘伟.zip”主要涵盖了Java设计模式的学习与应用,特别是针对刘伟教授的相关课程的课后习题及模拟试题的解答。 设计模式分为三大类:创建型、结构型和行为型模式。...
在这个“设计模式作业——用命令模式java语言编写的烧烤店”项目中,我们将探讨如何运用命令模式来构建一个模拟烧烤店的系统。命令模式是一种行为设计模式,它将请求封装为一个对象,使得我们可以参数化不同的请求、...
命令模式是一种行为设计模式,它将请求封装为一个对象,从而使你可用不同的请求对客户进行参数化,对请求排队或记录请求日志,以及支持可撤销的操作。在软件工程中,这种模式常用于解耦发出命令的对象(调用者)与...
目录: 前 言 第一部分 大旗不挥,谁敢冲锋——热身篇 第1章 单一职责原则 1.1 我是“牛”类,我可以担任多职吗 1.2 绝杀技,打破你的传统思维 1.3 我单纯,所以我快乐 1.4 最佳实践 ...附录:23个设计模式
### Java设计模式经典教程知识点概览 #### 一、设计模式概述 设计模式是一种软件设计方法,它为软件开发者提供了一种标准化的方式去解决常见的软件设计问题。设计模式的使用可以提高代码的可读性和可维护性,同时...
在软件设计领域,设计模式作为面向对象编程中的重要概念,一直备受关注。它们是解决问题的模板,能够帮助开发人员在面对相似问题时...在学习和工作中,深入了解并应用命令模式,将能够帮助我们面对更加复杂的编程挑战。
总结来说,Java设计模式的学习是一条不断深化的过程,它从UML开始,到设计模式的具体分类和应用,再到软件设计原则的领悟,每一步都是提升个人技术能力的重要环节。通过不断的学习和实践,开发者能够成为一名更加...
根据提供的标题、描述以及部分内容,本文将深入探讨Java设计模式,并着重分析23种常见的设计模式,以帮助Java程序员更好地理解和应用这些模式。 ### Java设计模式概述 Java设计模式是面向对象软件设计的一种通用可...
《Java与模式》是闫宏大师的一部经典之作,它将古老的哲学智慧——道德经的智慧,巧妙地融入到现代编程语言Java的设计模式之中。这本书不仅深入浅出地讲解了23种经典的设计模式,还提供了丰富的实践案例,旨在帮助...
在编程世界中,Java设计模式是面向对象编程领域的一个重要概念,它为解决常见的软件设计问题提供了可重用的解决方案。对于新手来说,设计模式可能显得深奥难懂,但它们实际上是经验丰富的开发者用来提高代码质量、可...
### Java设计模式(1)——理解与应用 #### 一、设计模式概述 设计模式是在软件工程领域中,为了应对特定问题或情境而形成的最佳实践集合。这些模式可以帮助开发者更高效地解决常见问题,提高代码的可重用性和可...
### JAVA设计模式总结之23种设计模式及六大原则 #### 一、设计模式之六大原则 ##### 总原则:开闭原则(Open Close Principle) 开闭原则是设计模式中最核心的原则之一,它强调的是软件实体(类、模块、函数等)...
设计模式是软件工程中的一种最佳实践,它是在特定上下文中解决常见问题的模板或蓝图。...通过阅读《设计模式——Java语言中的应用》这本书,你可以更深入地学习和掌握这些模式的细节及其在实际开发中的应用。
本文将深入探讨两种重要的设计模式——命令模式和责任链模式,并通过Java代码实例来阐述它们的应用和实现。 首先,我们来看**命令模式**。命令模式的核心思想是将请求封装为一个对象,从而可以将命令参数化、支持...
《JAVA设计模式(中文).chm》是一部专为Java开发者准备的设计模式指南,它深入浅出地阐述了软件工程中的重要概念——设计模式。设计模式是解决常见编程问题的成熟解决方案,是经验丰富的开发者们在实践中总结出的最佳...
在课程设计报告中,学生可能详细描述了项目的实现过程,包括选择的技术、遇到的问题及解决方案、代码结构和设计模式等。报告还可能涵盖了测试部分,包括单元测试和集成测试,以确保程序的稳定性和正确性。 总的来说...
**JAVA设计模式——核心概念与应用** 设计模式是软件开发中的宝贵经验总结,它们是针对常见问题的可重用解决方案。在Java编程中,设计模式是提升代码质量、可维护性和扩展性的关键。《JAVA设计模式.影印版》这本书...