headfirst设计模式读书总结——命令模式.doc

headfirst设计模式读书总结——命令模式
在本章，我们将把封装带到一个全新的境界：把方法调用(method invocation)封装起来。通过封装发发调用，我们可以把运算块包装成形。所以调用此运算的对象不需要关心事情是如何进行的。只要知道如何使用包装成形的方法来完成它就可以。通过封装方法调用，也可以做一些很聪明的事情，例如记录日志，或者重复使用这些封装来实现撤销(undo)。
题例：家电自动化
设计一个家电自动化遥控器的API。这个遥控器具有七个可编程的插槽，每个插槽都有对应的开关按钮，这个遥控器还具备一个整体的撤销按钮。希望你能够创建一组控制遥控器的API，让每个插槽都能够控制一个或一组装置，能够控制目前的装置和任何未来可能出现的装置，这一点很重要。(这里有一组Java类，这些类时由多个厂商开发出来的，用来控制家电自动化装置，例如点灯，风扇，热水器，音响设备和其他类似的可控制装置。)上面是很多的厂商类，看不清不要紧。你只要知道它很多，控制各种电器。
有许多类都具备on()和off()方法，除外还有其他的一些方法。
遥控器应该知道如何解读按钮被按下的动作，然后发出正确的请求，但是遥控器不需要知道这些家电自动化的细节，或者如何打开热水器。
提示：命令模式可将“动作的请求者”从“动作的执行者”对象中解耦，在我们的题例中，请求者是遥控器，而执行者对象就是厂商类。利用命令对象，把请求(打开点灯)封装成一个特定对象(客厅点灯对象)，如果对每个按钮都存一个命令对象，那么当按钮被按下的时候，就可以请命令对象做相关的工作，遥控器并不需要知道工作内容是什么，只要有个命令对象能和正确的对象沟通，把事情做好久可以了。
命令模式的简单介绍
(如果你已经理解命令模式可以不看下面的例子)
餐厅解析：研究顾客，女招待，订单，以及快餐厨师之间的交互。
1：你，也就是顾客，把订单交个女招待。
2：女招待拿了订单放在订单柜台，然后喊了一声“订单来了”。
3：快餐厨师根据订单准备餐点。
让我们更详细地研究这个交互
顾客知道自己要吃什么，并创建了一张订单createOrder()，订单包含一个订单表格，顾客订购的餐点项目写在上面。女招待拿走了订单tekeOrder()，放在订单柜台，然后调用orderUp()方法，通知厨师准备餐点。订单上有所有准备餐点是只是，知道厨师用类似makeBurger()这样的方法来烹饪。开餐厨师准备餐点。output()。
餐厅的角色和职责
一张订单封装了准备餐点的请求。
把订单想象成一个用来请求准备餐点的对象，和一般的对象一样，订单对象可以被传递：从女招待传递到订单柜台，或者从女赵丹传递到阶梯下一班的女找到，订单的接口只包含一个方法就是orderUp()。这个方法封装了准备从哪点所需的动作。订单内有一个到
“需要进行准备工作的对象”(也就是厨师)的引用。这一切都被疯转起来，所以女招待不需要知道订单上有什么，也不需要知道是谁来准备餐点。
女招待的工作是接收订单，然后调用订单的orderUp()方法。
女招待其实不必担心订单的内容是什么，或者由谁来准备餐点，她只需要知道，订单有一个orderUp()方法可以调用，这就够了。
快餐厨师具备准备餐点的知识。
快餐厨师是一种对象，他真正知道如何准备餐点，一旦女找到调用orderUp()方法，快餐厨师就接手，实现需要创建餐点的所有方法，女找到和厨师之间是彻底的解耦，女招待的订单封装了餐点的细节，厨师只要调用每个订单的方法即可。
把采纳定想着一种设计模式的一种模型，而这个模型允许将“发出请求的对象”和“接收与执行这些请求的队形”分隔开来，对于遥控器API，我们需要分隔开“发送请求的按钮”和“执行请求的厂商特定对象”。
第一个命令对象
实现命令接口
首先，让所有的命令对象实现相同的包含一个方法的接口，在餐厅的例子中，我们称此方法为orderUp(),然而，现在改为一般惯用的名称execute()。
interface Command{
public void execute();
}
实现一个打开点灯的命令
建设想实现一个打开点灯的命令，根据厂商提供的类，Light有两个方法：on()和off()。
class LightOnCommand implements Command{
Light light;
public LightOnCommand(Light light){
=light;
}
***@Override
public void execute() {
light