设计模式 - 命令模式

前言

命令模式是从界面设计中提取出来的一种分离耦合，提高重用的方法。(注意只是从页面设计中提取出来的一种分离耦合，不代表只能在页面是使用的设计)

定义

将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

解决的问题

在设计界面时，同样的菜单控件，在不同的应用环境中的功能是完全不同的；而菜单选项的某个功能可能和鼠标右键的某个功能完全一致。

理解

*客户发出请求给请求者，请求者下发命令，这个命令是给某个具体的接受者里执行的。*请求者(command(receiver))

结构

command
定义命令的接口，声明执行的方法。
ConcreteCommand
命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。
Receiver
接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。
Invoker
要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
Client
创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行。

命令是唯一的，一个命令可能可以有多个接受者可以实现他，所以在java中而已，一个命令可以就是接口的一个方法(代表了一个操作类型)
而请求，却可能是多样的，对于前台页面开发而言，一个同样的按钮，当你点击的时候，A：代表的是search，B：代表的是add。
这时是请求，当你按下按钮之后，请求会命令系统完成search，或add 的命令。但是对于search来说，我可能是根据Id来search，也可能是根据age来search。这时就是因为接受者不一样，而产品search的结构不同。

我做过的系统理解
Action跳转：
在页面上我们经常会点击save按钮，和search按钮，这是系统会对这两种按钮做出不同的反映。但是进入系统后我们会发现，无论是search还是save，他们走的action都是同一个***action，系统会根据sactionType的不同，走不同的分支，这里action是请求者
当到达某一个具体的sActionType的时候，我们会通过调用Spring中配置的service(这个在spring中special出来的service就是接受者)来执行search(这个命令)操作，这时，根据service的具体实现不同时，我的search的结果也会不通过，这就是一个完整的命令模式。