命令模式

命令模式把封装带到一个全新的境界：把方法调用封装起来。通过封装方法调用，我们可以把运算块包装成形。所以调用此算法的对象不需要关心事情是如何进行的，只要知道如何使用包装成形的方法来完成它就可以。通过封装方法调用，也可以做一些很聪明的事情，例如记录日志，或者重复使用这些封装来实现撤销。

1.定义

将“请求”封装成对象，以便使用不同的请求，队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。

2.例子

我们都知道餐厅是怎么工作的：
顾客把订单交给女招待，女招待拿了订单，放在订单柜台，然后喊了一声“订单来了！” 快餐厨师根据订单准备餐点。

命令模式可将“动作的请求者”从“动作的执行者”对象中解耦。在例子中，请求者可以是女招待，而执行者对象就是快餐厨师。顾客知道他要的是什么，并创建一张订单（createOrder()），订单包含一个订单表格，顾客订购的餐点项目写在上面。女招待拿走了订单（takeOrder()），放在订单柜台，然后调用（orderUp()）方法，通知初始开始准备餐点。订单上有所有准备餐点的指示，知道厨师用类似（makeBurger()）这样的方法来烹调，快餐厨师根据指令准备餐点。
参订中角色和职责：
①一张订单封装了准备餐点的请求。
把订单想象成一个用来请求准备餐点的对象，和一般的对象一样，订单对象可以被传递：从女招待传递到订单柜台，或者从女招待传递到接替下一班的女招待。订单的接口只包含一个方法，也就是orderUp()。这个方法封装了准备餐点所需要的动作。订单内有一个到“需要进行准备工作的对象”（也就是厨师）的引用。这一切都被封装起来，所以女招待不需要知道订单上有什么，也不需要知道是谁来准备餐点；她只需要将订单放到订单窗口，然后喊一声“订单来了”就可以了。
②女招待的工作是接受订单，然后调用订单的orderUp()方法。
女招待的工作很简单：接下顾客的订单，继续帮助下一个顾客，然后将一定数量的订单放到订单柜台，并调用orderUp()方法，让人来准备餐点。女招待其实不必担心订单的内容是什么，或者由谁来准备餐点。她只需要知道，订单有一个orderUp()方法可以调用，这就够了。现在，一天内，不同的顾客有不同的订单，这会使得女招待的takeOrder()方法被传入不同的参数。女招待知道所有的订单都支持orderUp()方法，任何时候她需要准备餐点时，调用这个方法就是了。
③快餐厨师具备准备餐点的知识
快餐厨师是一种对象，他真正知道如何准备餐点。一旦女招待调用orderUp()方法，快餐厨师就接手，实现需要创建餐点的所有方法，请注意，女招待和厨师之间是彻底的解耦：女招待的订单封装了餐点的细节，她只要调用每个订单的方法即可，而厨师看了订单就知道该做些什么餐点；厨师和女招待之间从来不需要直接沟通。

3.特性

主要解决：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
何时使用：在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。
如何解决：通过调用者调用接受者执行命令，顺序：调用者→接受者→命令。
优点： 1、降低了系统耦合度。 2、新的命令可以很容易添加到系统中去。
缺点：使用命令模式可能会导致某些系统有过多的具体命令类。