`
zzq19860626
  • 浏览: 261019 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
博客专栏
B20df9e2-fb3d-3644-9f72-c1619842f682
设计模式学习笔记
浏览量:177982
87eaf24f-812a-3463-8e65-e3197d2ad8c2
java虚拟机
浏览量:26189
社区版块
存档分类
最新评论

JAVA设计模式学习21——命令模式

阅读更多
命令(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,或者记录日志等。

 

 

设计模式系列目录:

  • 大小: 27.3 KB
  • 大小: 20.8 KB
7
8
分享到:
评论
16 楼 lee_govern 2013-12-26  
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继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?

作者的例子举得很好,我试试继续用这个例子来解析这样设计的好处吧。万一有一天GameMachine的move实现改变了,move的同时要加上run(GameMachine定义的新方法),那么只需要在Control的move方法中加上GameMachine的run调用,而不是修改那无数个Client的move方法。
15 楼 dingran 2013-08-27  
解耦很关键,这是关键,哈哈。
14 楼 hialaric 2013-08-23  
写的不错 
13 楼 zzq19860626 2013-08-23  
fykyx521 写道
其实模式遵守那几个原则 
把原则比作接口  模式只是原则的具体实现
理论上是不遵重原则就行了(实现原则接口),具体模式不一定强迫用
我很少用设计模式,只是让自己代码走的比较舒服,可能研究部深

其实有时候你已经用到了设计模式,只是自己不知道而已。
12 楼 fykyx521 2013-08-23  
其实模式遵守那几个原则 
把原则比作接口  模式只是原则的具体实现
理论上是不遵重原则就行了(实现原则接口),具体模式不一定强迫用
我很少用设计模式,只是让自己代码走的比较舒服,可能研究部深
11 楼 strivezsh 2013-08-22  
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继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?


首先,您的这种想法在国内众多开发者中普遍存在,至少让我来做的话,我有很大的概率会选择您的做法,理由很简单,开发起来方便。
但这边讨论的是设计模式,设计模式有很多个原则,其中有一条说的是:类应该对修改关闭,对扩展开放。是什么意思和为什么要这么做,请自己google吧。您说的如果要添加一个命令的功能,只需添加一个函数而已,这点在实现上确实是如此的。但请考虑到扩展问题,每天加一个新命令就需要修改下原有的代码,如果说这代码还是由你来负责,我想依您的实力应该没什么问题,那万一这代码不再由您负责了呢,面对一大串的函数,我想没人会觉得轻松吧。当然,您可以说"反正不是我负责了,不关我的事",但如果是别人写的这一大串代码给你去修改呢,情况又会如何

这个解释够清楚了!

其实吧 是这个人 不懂得 什么 叫做 举个栗子
10 楼 zzq19860626 2013-08-22  
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继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?


首先,您的这种想法在国内众多开发者中普遍存在,至少让我来做的话,我有很大的概率会选择您的做法,理由很简单,开发起来方便。
但这边讨论的是设计模式,设计模式有很多个原则,其中有一条说的是:类应该对修改关闭,对扩展开放。是什么意思和为什么要这么做,请自己google吧。您说的如果要添加一个命令的功能,只需添加一个函数而已,这点在实现上确实是如此的。但请考虑到扩展问题,每天加一个新命令就需要修改下原有的代码,如果说这代码还是由你来负责,我想依您的实力应该没什么问题,那万一这代码不再由您负责了呢,面对一大串的函数,我想没人会觉得轻松吧。当然,您可以说"反正不是我负责了,不关我的事",但如果是别人写的这一大串代码给你去修改呢,情况又会如何

这个解释够清楚了!
9 楼 ljqian 2013-08-22  
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继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?


首先,您的这种想法在国内众多开发者中普遍存在,至少让我来做的话,我有很大的概率会选择您的做法,理由很简单,开发起来方便。
但这边讨论的是设计模式,设计模式有很多个原则,其中有一条说的是:类应该对修改关闭,对扩展开放。是什么意思和为什么要这么做,请自己google吧。您说的如果要添加一个命令的功能,只需添加一个函数而已,这点在实现上确实是如此的。但请考虑到扩展问题,每天加一个新命令就需要修改下原有的代码,如果说这代码还是由你来负责,我想依您的实力应该没什么问题,那万一这代码不再由您负责了呢,面对一大串的函数,我想没人会觉得轻松吧。当然,您可以说"反正不是我负责了,不关我的事",但如果是别人写的这一大串代码给你去修改呢,情况又会如何
8 楼 ifox 2013-08-21  
已經在看啦。
多謝
7 楼 zzq19860626 2013-08-21  
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继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?

首先这里欢迎所有人来拍砖。每设计模式是一种思想,是前人总结的经验,但它是有使用场合的,如果我们写个test或者练习的main方法,用设计模式显得多余,。上文中,直接
//machine.fist(); 
//machine.kick(); 
//machine.move("左");
减少类,减少调用流程, 多简单;但是这里是讲设计模式,设计模式的目的是提高系统的可扩展性、可维护性。
6 楼 suneyejava 2013-08-21  
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继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?


照你这么说,所有的设计模式都没任何用处了?要做大项目设计模式是必须的。
5 楼 chenqidou 2013-08-21  
原文代码: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继续添加命令函数。过程谁复杂,不言而喻吧...
后面的几个优点在第一个优点的影响下,还能算优点么?
4 楼 zzq19860626 2013-08-21  
jayung 写道
顶,iteye有你更精彩。

谢谢围观~
3 楼 jayung 2013-08-21  
顶,iteye有你更精彩。
2 楼 zzq19860626 2013-08-21  
谷超 写道
帅气,写了这么多的设计模式的文章,有时间细细研读体会!

谢谢关注,欢迎拍砖。
1 楼 谷超 2013-08-21  
帅气,写了这么多的设计模式的文章,有时间细细研读体会!

相关推荐

    设计模式作业——用命令模式java语言编写的烧烤店

    设计模式作业——用命令模式编写的烧烤店。

    java设计模式

    目录: 前 言 第一部分 大旗不挥,谁敢冲锋——热身篇 第1章 单一职责原则 1.1 我是“牛”类,我可以担任多职吗 1.2 绝杀技,打破你的传统思维 1.3 我单纯,所以我快乐 1.4 最佳实践 ...附录:23个设计模式

    详解Java设计模式——命令模式

    主要介绍了Java设计模式——命令模式,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧

    Java设计模式 版本2

    Java设计模式,目录:前言,UML建模技术,深入浅出UML类图,从招式与内功谈起——设计模式概述,面向对象设计原则,工厂三兄弟之简单工厂模式,工厂三兄弟之工厂方法模式,工厂三兄弟之抽象工厂模式,确保对象的唯一...

    深入浅出设计模式(中文版电子版)

    4.4.2现实中的装饰模式——相架 126 4.4.3C#实例——图书馆中的项目 127 4.4.4Java实例——自定义JButton 131 4.4.5优势和缺陷 133 4.4.6应用情景 134 4.5FacadePattern(外观模式) 134 4.5.1定义 134 4.5.2...

    深入浅出设计模式(中文版)

    4.4.2现实中的装饰模式——相架 126 4.4.3C#实例——图书馆中的项目 127 4.4.4Java实例——自定义JButton 131 4.4.5优势和缺陷 133 4.4.6应用情景 134 4.5FacadePattern(外观模式) 134 4.5.1定义 134 4.5.2...

    design-pattern-java.pdf

    命令模式-Command Pattern 请求发送者与接收者解耦——命令模式(一) 请求发送者与接收者解耦——命令模式(二) 请求发送者与接收者解耦——命令模式(三) 请求发送者与接收者解耦——命令模式(四) 请求发送者...

    java高手真经 (UML建模+设计模式+面向服务架构) 卷6

    综合实例——Bug管理系统 (3)设计模式样例(24个讲解样例程序) pattern/src/principle/liskovsubstitution//10.3.2里氏代换原则 pattern/src/creation/factorymethod //11.1工厂方法模式 pattern/src/creation/...

    java高手真经 (UML建模+设计模式+面向服务架构) 卷8

    综合实例——Bug管理系统 (3)设计模式样例(24个讲解样例程序) pattern/src/principle/liskovsubstitution//10.3.2里氏代换原则 pattern/src/creation/factorymethod //11.1工厂方法模式 pattern/src/creation/...

    浅谈简单工作流设计——责任链模式配合策略与命令模式的实现

    本文以项目中的一个工作流模块,演示责任链模式、策略模式、命令模式的组合实现!最近在做的一个项目,涉及到的是一个流程性质的需求。关于工程机械行业的服务流程:服务任务流程和备件发运流程。项目之初,需求不是...

    java高手真经 (UML建模+设计模式+面向服务架构) 卷3

    pattern/src/behavior/command //13.6命令模式 pattern/src/behavior/memento //13.7备忘录模式 pattern/src/behavior/state //13.8状态模式 pattern/src/behavior/visitor //13.9访问者模式 pattern/src/...

    java高手真经 (UML建模+设计模式+面向服务架构) 卷1

    pattern/src/behavior/command //13.6命令模式 pattern/src/behavior/memento //13.7备忘录模式 pattern/src/behavior/state //13.8状态模式 pattern/src/behavior/visitor //13.9访问者模式 pattern/src/...

    java高手真经 (UML建模+设计模式+面向服务架构) 卷9

    综合实例——Bug管理系统 (3)设计模式样例(24个讲解样例程序) pattern/src/principle/liskovsubstitution//10.3.2里氏代换原则 pattern/src/creation/factorymethod //11.1工厂方法模式 pattern/src/creation/...

    【白雪红叶】JAVA学习技术栈梳理思维导图.xmind

    命令模式 解释器模式 迭代器模式 中介者模式 备忘录模式 观察者模式 状态模式 策略模式 模板方法模式 访问者模式 设计案例 UML 架构 系统架构能力 基本理论 扩展性设计 可用性设计 可靠性设计 ...

    设计模式Demo

    行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类:并发型模式和线程池模式。 二、设计...

    java高手真经 (UML建模+设计模式+面向服务架构) 卷10

    综合实例——Bug管理系统 (3)设计模式样例(24个讲解样例程序) pattern/src/principle/liskovsubstitution//10.3.2里氏代换原则 pattern/src/creation/factorymethod //11.1工厂方法模式 pattern/src/creation/...

    java高手真经 (UML建模+设计模式+面向服务架构) 卷5

    综合实例——Bug管理系统 (3)设计模式样例(24个讲解样例程序) pattern/src/principle/liskovsubstitution//10.3.2里氏代换原则 pattern/src/creation/factorymethod //11.1工厂方法模式 pattern/src/creation/...

    java高手真经 (UML建模+设计模式+面向服务架构) 卷7

    综合实例——Bug管理系统 (3)设计模式样例(24个讲解样例程序) pattern/src/principle/liskovsubstitution//10.3.2里氏代换原则 pattern/src/creation/factorymethod //11.1工厂方法模式 pattern/src/creation/...

    java高手真经 (UML建模+设计模式+面向服务架构) 卷2

    pattern/src/behavior/command //13.6命令模式 pattern/src/behavior/memento //13.7备忘录模式 pattern/src/behavior/state //13.8状态模式 pattern/src/behavior/visitor //13.9访问者模式 pattern/src/...

Global site tag (gtag.js) - Google Analytics