每天一个（Java设计模式）-- Command模式

每一个模式，如果乍一看，可能都很好理解，但是却不知所用。
一个好的模式，是从实践中的出来的，所以，要想很好的理解模式，就必须做很多的实际工作，在这些工作中去体会模式为什么是这样的。
    事实上，当这些所谓的模式被抽象出来以后，就很难还原这个模式所解决问题的场景了。于是我们看到的都是些教学例子，看起来简单，实际上却并不理想，很可能看完就忘记了。
    好了废话不多说，我并非是说理的，只是整理一下一些常用的设计模式，并加上自己的看法罢了，留作日后好查阅。
    今天来说说命令模式吧。这个模式一直是比较模糊的，感觉没什么东西，就记得有个命令接口，里面放个execute方法。网上很多网友说都说，这是一个解耦合的模式，把命令的发起者和执行者分开。仔细算来，搞出很多角色名堂了。那么我们先看看他的UML吧。


从图中可以看到，有5个角色
1：使用者
2：调用者
3：命令接口
4：命令实现者
5：接收者

从图中可以看到，实际上命令是不做什么事情的，只是传话的功能。真正处理命令的是接收者，而决定谁来接收命令的是使用者，也就是发命令的人。

好了，这些关系搞清楚了，这个机制也就明白了。接下来就是如何灵活运用了。

现在，我们来看看熟悉的java Swing Menu中的运用吧，也许你会惊讶，原来这样也是命令模式！

class ML implements ActionListener{
		public void actionPerformed(ActionEvent e){
			JMenuItem m = (JMenuItem)e.getSource();
			String commandString = m.getActionCommand();
			if(commandString.equals("Open")){
				//do something
			}
		}
	}

菜单项

JMenuItem mi = new JMenuItem("myMenu");
...
                mi.setActionCommand("Guard");
		mi.addActionListener(new ML());
		

这里我们看到，菜单项可以设置命令，菜单项在这里好比是调用者。命令就是ActionListener,而接收者是由用户自己定义的。我们可以再actionPerformed中写自己对命令的响应。这不就是一个命令模式吗？当然，这里缺少了一个接收者，当然我们也可以加进去。

对于命令模式来说，运用的场合很多，但是我们还是不知道，为什么一定要命令模式呢？

就一个简单的问题，如果不用命令模式，我们会写成什么样的代码呢？

if("Guard".equals(clickString))
{
   //do something
}else if("Hide".quals(clickString))
{
  //do another 
}
...

如果不用命令模式，我们的代码很可能如上所述，不仅仅是if else泛滥，而且，当我们需要一个新的命令时，我们可能要修改原有代码，这个在OO设计中，违反了OCP原则，是很糟糕的事情，我们更愿意添加新的命令类来实现而不改变原有代码。

说到这里，我们也许发现，这样的话，很可能多出很多命令类来。导致类的泛滥。这里就要具体问题具体分析了，如果一个使用了命令模式的设计，可能导致类的泛滥，那么我们是否改进一下这个模式呢？

这里再抽象一下，调用者负责命令的装配和调用，所以在这个环节，我们可以只使用一个命令类，但是装配不同的接收者，这样，就可以减少类的使用了。

命令模式对于这样的场景，也是很适合的。比如需要撤销操作。
通过往命令模式中存入命令执行前的状态（或者日志），当撤销时，就可以恢复到执行命令前的状态了。所以，命令模式在事务处理中，比较合适。

除了这些，命令模式在MVC 框架下的应用中也是非常广泛。容器就是使用者，Controller就是一个Invoker，而Action实际上就是一个基本的命令，我们要做的就是配置各种命令与接收者来实现不同的请求。

实际上，Java的多线程机制也是是一个命令模式。

当我们需要执行一个未知（对于调用者）的行为时，我们可以考虑使用命令模式。但是这里要弄清楚，作为命令的使用者来说，由谁调用，调用是什么命令，谁来执行都是知道的。

到这里，如果经常使用c/c++的朋友，或许看出来了，命令模式中的命令就是个纯虚函数接口。有了这种抽象的东西，世界就变得美好了。我们不必把什么命令都绑定到某个人身上，这个命令可以由任何人去完成，不到下达命令的时候，谁也不知道谁将会是接收者！