Why are we, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, called this? Who knows. Somehow the name just stuck. Hopefully like, the original Gang of Four, we have started a small cultural change with "Design Patterns..." And hopefully unlike the original Gang of Four we will not meet such an untimely end for our ("counter-revolutionary"?) ideas.

Erich Gamma is currently with a consulting group in Zurich whose name I (Ralph) can't recall. From 1993 to 1995, he was a software engineer at Taligent working on their object-oriented development environment. Erich was previously at UBILAB research laboratory of Union Bank of Switzerland. He was one of the architects of ET++, a portable C++ class library for developing interactive graphical applications. Erich has a Ph.D. in Computer Science from University of Zurich.

Richard Helm recently rejoined IBM to start the Australian branch of the Object Technology Practice. Prior to that, he was a technology consultant with DMR Group, an international information technology consulting firm. There he actively applied design patterns to the design of commercial systems. Prior to DMR, Richard was in the Software Technology department at IBM T.J. Watson Research Center investigating object-oriented design and reuse and visualization. Richard has numerous international publications, writes regularly in Dr. Dobb's Journal, and is a past OOPSLA program committee member. Richard has a Ph.D. in Computer Science from the University of Melbourne, Australia.

Ralph Johnson has been studying object-oriented technology and how it changes the way that software is developed for the past 10 years. He has been involved in the development of an object-oriented operating system (Choices), compiler (Typed Smalltalk), graphics editor framework (HotDraw), music synthesis system (Kyma), and is currently working on a framework for accounting. He is on the faculty of the Department of Computer Science at the University of Illinois and has helped organize several OOPSLA's, including OOPSLA'93 as program chair. He got his PhD from Cornell.

John Vlissides passed away November 24th, 2005. He was a researcher at the IBM T.J. Watson Research Center. His research interests included object-oriented design tools and techniques, application frameworks and builders, and program visualization. Before IBM, John was at the Computer Systems Laboratory at Stanford University. There he co-developed InterViews, a popular object-oriented s

先来验证下第二个特性：

public class TestPattern {

       public static void main(String[] args){

              String n = "I Love Java";

              String m = "I Love Java";            

              System.out.println(n==m);

       }

}

这段代码会告诉你n==m是true，这就说明了在JVM中n和m两个引用了同一个String对象（如果你还分不清== 和 equals的区别的话，请先确认）。

那么接着验证下第一个特性：

在系统输出之前加入一行代码“m = m + "hehe";”，这时候n==m结果为false，为什么刚才两个还是引用相同的对象，现在就不是了呢？原因就是在执行后添加语句时，m指向了一个新创建的String对象，而不是修改引用的对象。

呵呵，说着说着就差点跑了题，并不是每个String的特性都跟我们今天的主题有关的。
      String类型的设计避免了在创建N多的String对象时产生的不必要的资源损耗，可以说是享元模式应用的范例，那么让我们带着对享元的一点模糊的认识开始，来看看怎么在自己的程序中正确的使用享元模式！

享元模式:运用共享技术有效地支持大量大量细粒度的对象.

享元模式英文称为“Flyweight Pattern”，我非常感谢将Flyweight Pattern翻译成享元模式的那位强人，因为这个词将这个模式使用的方式明白得表示了出来；如果翻译成为羽量级模式或者蝇量级模式等等，虽然可以含蓄的表现出使用此模式达到的目的，但是还是没有抓住此模式的关键。

享元模式的定义为：采用一个共享来避免大量拥有相同内容对象的开销。这种开销中最常见、直观的就是内存的损耗。享元模式以共享的方式高效的支持大量的细粒度对象。

在名字和定义中都体现出了共享这一个核心概念，那么怎么来实现共享呢？要知道每个事物都是不同的，但是又有一定的共性，如果只有完全相同的事物才能共享，那么享元模式可以说就是不可行的；因此我们应该尽量将事物的共性共享，而又保留它的个性。为了做到这点，享元模式中区分了内蕴状态和外蕴状态。内蕴状态就是共性，外蕴状态就是个性了。

注：共享的对象必须是不可变的，不然一变则全变（如果有这种需求除外）。
   内蕴状态存储在享元内部，不会随环境的改变而有所不同，是可以共享的；外蕴状态是不可以共享的，它随环境的改变而改变的，因此外蕴状态是由客户端来保持（因为环境的变化是由客户端引起的）。在每个具体的环境下，客户端将外蕴状态传递给享元，从而创建不同的对象出来。至于怎样来维护客户端保持的外蕴状态和享元内部保持的内蕴状态的对应关系，你先不用担心这个问题，我们后面会涉及到的。

我们引用《Java与模式》中的分类，将享元模式分为：单纯享元模式和复合享元模式。在下一个小节里面我们将详细的讲解这两种享元模式。

享元模式的组成部份:
1.享元接口 定义了享元
2.具体享远 实现享元接口
3.享元工厂 负责管理和创建享元对象,一般包含一个Map, 保存享元对象,使用都请求享元时,先到map里找是否有这个享元,如果有,返回,没有就创建该享元.机制有点像对时所做的简单的缓存.
各部份的组成关系:

使用优缺点

享元模式优点就在于它能够大幅度的降低内存中对象的数量；而为了做到这一步也带来了它的缺点：它使得系统逻辑复杂化，而且在一定程度上外蕴状态影响了系统的速度。

所以一定要切记使用享元模式的条件：

1)        系统中有大量的对象，他们使系统的效率降低。

2)        这些对象的状态可以分离出所需要的内外两部分。

外蕴状态和内蕴状态的划分以及两者关系的对应也是非常值得重视的。只有将内外划分妥当才能使内蕴状态发挥它应有的作用；如果划分失误，在最糟糕的情况下系统中的对象是一个也不会减少的！两者的对应关系的维护和查找也是要花费一定的空间（当然这个比起不使用共享对象要小得多）和时间的，可以说享元模式就是使用时间来换取空间的。在Gof的书中是使用了B树来进行对应关系查找优化。

总结
      也许你要长叹一声：这个享元模式未必太复杂了吧！这点是不得不承认的，也许由于它的复杂，实际应用也不是很多，这是我们更加无法看清他的真面目了。不过享元模式并不是鸡肋，它的精髓——共享是对我们系统优化非常有好处的，而且这种思想已经别越来越多的应用，这应该就算是享元模式的应用了吧。如果你已经领会到了享元模式的精髓，那么也就是掌握了享元模式了!

    匆匆学完了享元模式，不知道理解上有没有纰漏，希望大家能指正出来，一起共同进步！其实我一直想使用一个实际系统中或者实践中的例子来讲解享元模式，可是毕竟自己的工作经验太少了！！于是想在网上找一些灵感来，可是狂搜一阵子也没有发现什么，于是就又落俗套的使用了一个比喻的例子。如果您对此深有体会的话，还烦请不吝赐教！！

状态模式：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
状态模式的组成部份:
1.环境,是一个类,该类含有抽象状态声明的变量,可引用具体的状态实例,用户对环境类的实例在某一些状态的行为感兴趣.
2.抽象状态,抽象状态是一个接口名抽象类,抽象状态中定义了与环境的一个特定状态相关的若干方法.
3.具体状态,实现抽象接口
各组成部份之间的关系:

例子
1.状态:

package state;

/** *//**
 * <ul>
 * <li>Title:[IState]</li>
 * <li>Description: [状态接口]</li>
 * <li>Copyright 2009 Upengs Co., Ltd.</li>
 * <li>All right reserved.</li>
 * <li>Created by [Huyvanpull] [2011-8-2]</li>
 * <li>Midified by [modifier] [modified time]</li>
 * </ul>
 * @version 1.0  
 */
public interface IState
{   
    /** *//**
     * <ul>
     * <li>Description:[显示状态]</li>
     * <li>Created by [Huyvanpull] [2011-8-2]</li>
     * <li>Midified by [modifier] [modified time]</li>
     * </ul>
     */
    public void showState();
}

2.具体状态1:

package state;

public class LowState implements IState
{
    public void showState()
    {
        System.out.println("低状态");
    }   
}

3.具体状态2

package state;

public class NormalState implements IState
{
    public void showState()
    {
        System.out.println("正常状态");
    }   
}

4.具体状态3

package state;

public class HeightState implements IState
{
    public void showState()
    {
        System.out.println("高状态");
    }
}

5.环境

package state;

public class StateMometer
{
    public IState state;
    
    public void showState()
    {
        state.showState();
    }

    public void setState(IState state)
    {
        this.state = state;
    }
}

6.测试

package state;

public class Test
{   
    public static void main(String[] args)
    {
        IState state = new LowState();
        
        StateMometer stateMoneter = new StateMometer();
        stateMoneter.setState(state);
        stateMoneter.showState();
        
        state = new NormalState();
        stateMoneter.setState(state);
        stateMoneter.showState();
        
        state = new HeightState();
        stateMoneter.setState(state);
        stateMoneter.showState();
        
    }
}

要点：

1． 策略模式和状态模式是双胞胎，它们有相同的类图，但是它们的意图不同。策略模式是围绕可以互换的算法来成功创建业务的,然而状态模式是通过改变对象内部的状态来帮助对象控制自己的行为.

2． Context将与状态相关的操作委托给当前的Concrete State对象处理。

3． Context可将自身作为一个参数传递给处理该请求的状态对象。这使得状态对象在必要时可访问Context。

4． Context或Concrete State类都可决定哪个状态是另外哪一个的后继者，以及是在何种条件下进行状态转换。也就是说可以在State中保存对Concrete State的引用，在必要时设置具体的状态，做到状态的转换。

5． 一般来讲，当状态转换是固定的时候，状态转换就适合放在Context中。然而，当转换是更动态的时候，通常会放到具体的状态类中进行。（具体状态类持有Context的引用，实现状态的转换）

适用性：

1. 一个对象的行为取决于它的状态 , 并且它必须在运行时刻根据状态改变它的行为。

2. 一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常，有多个操作包含这一相同的条件结构。 State模式将每一个条件分支放入一独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。

效果：

1. State模式将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。

State模式将所有与一个特定的状态相关的行为都放入一个对象中。因为所有与状态相关的代码都存在于某一个State子类中, 所以通过定义新的子类可以很容易的增加新的状态和转换。

另一个方法是使用数据值定义内部状态并且让Context操作来显式地检查这些数据。但这样将会使整个Context的实现中遍布看起来很相似的条件语句或case语句。增加一个新的状态可能需要改变若干个操作，这就使得维护变得复杂了。

State模式避免了这个问题,但可能会引入另一个问题,因为该模式将不同状态的行为分布在多个State子类中。这就增加了子类的数目，相对于单个类的实现来说不够紧凑。但是如果有许多状态时这样的分布实际上更好一些 , 否则需要使用巨大的条件语句。正如很长的过程一样，巨大的条件语句是不受欢迎的。它们形成一大整块并且使得代码不够清晰，这又使得它们难以修改和扩展。 State模式提供了一个更好的方法来组织与特定状态相关的代码。决定状态转移的逻辑不在单块的 if或switch语句中, 而是分布在State子类之间。将每一个状态转换和动作封装到一个类中，就把着眼点从执行状态提高到整个对象的状态。这将使代码结构化并使其意图更加清晰。

2. State对象可被共享。如果State对象没有实例变量，即它们表示的状态完全以它们的类型来编码，那么各Context对象可以共享一个 State对象。

因为一个复杂的对象,不但有很多大量组成部分,如汽车,有很多部件:车轮 方向盘 发动机还有各种小零件等等,部件很多,但远不止这些,如何将这些部件装配成一辆汽车,这个装配过程也很复杂(需要很好的组装技术),Builder模式就是为了将部件和组装过程分开.
生成器的组成部份:
   1.产品:  复杂对象  
   2.抽象生成器:抽象生成器是一个接口,该接口除了创建一个产品对象的各个组件定义了若干方法以外,还要定义返回project;
   3.具体生成器:实现抽象生成器的方法
   4.指挥者:它是一个类,该类含有抽象生成器的接口生成变量.它的职责是根据用户提供的生成器的种类来生成具体的产品对象.
生成器各部份之间的关系:

当客户需要一个产品时，把需要的参数传递个导向器，导向器根据传递的参数调用具体的生成器，具体的生成器通过一系列的操作(getAnimal()通过调用其它的接口方法实现)最会返回一个产品。

结论：生成器模式使得客户可以更加精细的控制一个对象的构建，每个具体的创建者包含了创建和装配一个特定产品的所有代码，这些代码只用写一次，便可以被不同的Director使用，从而可以装配出不同的对象。

和抽象工厂的区别:

    抽象工厂需要生产一个迷宫（Maze* maze），然后一步步生产迷宫。

    而生成器模式就不一样了，生成器（builder)封装了建造一个笔记本配件的方法。CreateMaze()只需要对这些配件进行组装。最后直接返回一个产品。

    这样看来工厂更像一种特殊的生成器，因为生成器也可以更换builder，生成器还能够生产不是一个系列的产品。即生成器不仅仅可以CreateMaze(),还可以生产CreateStandMaze()。类比到电脑，即不仅仅可以 CreateComputer(),还可以CreateComplexComputer()，更换builder也可以生产相同系列，不同的产品。

该模式和工厂方法模式很相似，也是一个抽象基类和若干个具体工厂类，不同的是抽象工厂的工厂基类定义了多个虚工厂方法，每个虚工厂方法负责返回一种产品，多个工厂方法返回多种产品，并且这些产品具有某些联系。
GOF 概扩: 提供一个一系列或相互依赖的接口,需无须指定它们的具体类.
抽象工厂模式的组成部份:
1.产品基类
2.具体产品
3.工厂基类
4.具体工厂
    抽象工厂就不止生产Nokia手机了，还生产相关的周边产品，首先NokiaFactory基类会定义两个虚方法，一个是CreateNokiaPhone用来生产手机，另一个是CreateNokiaCharger用于生产对应型号的手机充电器（假定不同型号手机使用不同的充电器）。然后派生类N97Factory就要生产两种相关的产品，一个是N97Phone,还有一个是N97Charger，这两个对象是对应的关系，因此封装到抽象工厂来生产一系列相关的对象。

    总结：用最简单的话来概括就是，简单工厂只有一个具体工厂类来创建一种基类的多个不同派生类，工厂方法就是有多个派生于一个基类的具体工厂类，每个具体工厂只生产一种基类的一个派生类，抽象工厂也是只有一个工厂基类，但是每个具体工厂生产多个相关基类的各一个派生类。

提供一种方法访问一个容器（container）对象中各个元素，而又不需暴露该对象的内部细节。
在迭代器模式中，具体迭代器角色和具体容器角色是耦合在一起的 —— 遍历算法是与容器的内部细节紧密相关的。为了使客户程序从与具体迭代器角色耦合的困境中脱离出来，避免具体迭代器角色的更换给客户程序带来的修改，迭代器模式抽象了具体迭代器角色，使得客户程序更具一般性和重用性。这被称为多态迭代
迭代器模式的组成部份
1.集合,一个接口,规定了具体集合需要实现的操作.
2.具体集合,是实现集合接口的实例,具体集合按着一定的结构存储对象,具体集合应当有一个方法返回针对该集合的具体迭代器.
3.迭代器, 一个接口,规定了遍历集合的方法.
4.具体迭代器
迭代器各组成部份之间的关系

例子:
集合:

package iterator;

public interface Aggregate<E>
{
    public Iterator<E> createIterator();
    
    public int length();
    
    public E get(int index);
    
    public void add(E obj);
}

具体集合:

package iterator;

import java.util.ArrayList;
import java.util.List;

public class ConcreteAggregate<E> implements Aggregate<E>
{
    private List<E> items = new ArrayList<E>();
    
    public Iterator<E> createIterator()
    {
        return new ConcreteIterator<E>(this);
    }
    
    public int length()
    {
        return items.size();
    }
    
    public E get(int index)
    {
        return (E) items.get(index);
    }
    
    public void add(E obj)
    {
        items.add(obj);
    }
    
}

迭代器:

package iterator;

public interface Iterator<E>
{
    public E first();
    
    public boolean hasNext();
    
    public E next();
    
    public E current();
}

具体迭代器:

package iterator;

public class ConcreteIterator<E> implements Iterator<E>
{
    private Aggregate<E> aggregate;
    
    private int currentIndex = 0;
    
    public ConcreteIterator(Aggregate<E> aggregate)
    {
        this.aggregate = aggregate;
    }
    
    public E first()
    {
        currentIndex = 0;
        if (hasNext())
        {
            return aggregate.get(currentIndex);
        }
        else
        {
            return null;
        }
    }
    
    public boolean hasNext()
    {
        return (currentIndex < aggregate.length());
    }
    
    public E next()
    {
        currentIndex++;
        if (hasNext())
        {
            return aggregate.get(currentIndex);
        }
        else
        {
            return null;
        }
    }
    
    public E current()
    {
        return aggregate.get(currentIndex);
    }
}

测试类:

package iterator;

public class Test
{
    public static void main(String[] args)
    {
        Aggregate<String> a = new ConcreteAggregate<String>();
        a.add("111");
        a.add("222");
        a.add("333");
        
        Iterator<String> it = a.createIterator();
        for (String s = it.first(); it.hasNext(); s = it.next())
        {
            System.out.println(s);
        }
    }
    
}

迭代器的优点:
      1、支持以不同的方式遍历一个容器角色。根据实现方式的不同，效果上会有差别。
      2、简化了容器的接口。但是在java Collection中为了提高可扩展性，容器还是提供了遍历的接口。
      3、对同一个容器对象，可以同时进行多个遍历。因为遍历状态是保存在每一个迭代器对象中的。

模式定义了一个高层接口，这个接口使得这一子系统更加容易使用
外观模式的组成部份:
1.子系统
2.外观类 包含每个子系统的类,并提供一个方法,按业务逻辑依次访问子系统里的方法,使之组成一个有机体
 例子:
读文件:

package facade;

public class ReadFile
{   
    public void readFile()
    {
        System.out.println("读文件");
    }
}

解析文件:

package facade;

public class ParseFile
{   
    public void parse()
    {
        System.out.println("解析文件");
    }
}

存文件:

package facade;

public class SaveFile
{   
    public void saveFile()
    {
        System.out.println("保存文件");
    }
}

外观类:

package facade;

public class Facade
{   
    // 解析文件
    private ParseFile parseFile;
    
    // 读文件
    private ReadFile readFile;
    
    // 保存文件
    private SaveFile saveFile;
    
    public Facade()
    {
        parseFile = new ParseFile();
        readFile = new ReadFile();
        saveFile = new SaveFile();
    }
    
    public void oparatFile()
    {
        this.readFile.readFile();
        this.parseFile.parse();
        this.saveFile.saveFile();
    }
}

正如上看到的说：客户端代码（Program）不需要关心子系统，它只需要关心CarFacade所留下来的和外部交互的接口，而子系统是在CarFacade中聚合。

 
Façade模式的几个要点：

       1、从客户程序的角度看，Facade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化。

2、Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。

 2种模式嫁接的方式不同。

      类适配器模式采用的是多重继承的方式

      class Adapter extends Adaptee implements Target{

            request(){this.SpecificRequest();}

            ....

     }

      对象适配器采用的是包含的方式

      class Adapter implements Taget{

           Adaptee adaptee;

           request(){adaptee.SpecificRequest();}

           ...

       }

      两者的区别我认为有以下几点

      1.类适配器模式需要创建自身来创建一个Adaptee,

        对象适配器模式可以直接使用一个已有的Adaptee的实例来转换接口。

      2. 类适配器继承了Adaptee,所以可以通过覆写来扩展SpecificRequest()

        对象适配器和Adaptee是包含关系不能扩展;(其实也可以扩展的见下面)

      3.类适配器模式因为是继承所以相对静态，而对象适配器模式是包含是组合相对灵活(可以通过写adaptee子类扩展功能)

package adapter;

public interface TwoElectricOutLet
{   
    public  void connectTwoElectricCurrent();
}

package adapter;

/** *//**
 * <ul>
 * <li>Title:[ThreeElectricOutlet]</li>
 * <li>Description: [三相电插座]</li>
 * <li>Copyright 2009 Upengs Co., Ltd.</li>
 * <li>All right reserved.</li>
 * <li>Created by [Huyvanpull] [2011-7-28]</li>
 * <li>Midified by [modifier] [modified time]</li>
 * </ul>
 * @version 1.0  
 */
public interface ThreeElectricOutlet
{   
    /** *//**
     * <ul>
     * <li>Description:[连接三相电]</li>
     * <li>Created by [Huyvanpull] [2011-7-28]</li>
     * <li>Midified by [modifier] [modified time]</li>
     * </ul>
     */
    public  void connectThreeElectricCurrent();
}

package adapter;

public class TreeElectricAdapter implements ThreeElectricOutlet
{
    TwoElectricOutLet twoElectricOutlet;
    
    public TreeElectricAdapter(TwoElectricOutLet twoElectricOutlet)
    {
        this.twoElectricOutlet = twoElectricOutlet;
    }
    public void connectThreeElectricCurrent()
    {
        System.out.print("变压器");
        this.twoElectricOutlet.connectTwoElectricCurrent();
    }   

}

观察者与后继动作

    对于观察者而言，除了监视被观察对象之外，更重要的是当发现被观察对象发生改变时应该采取什么样的动作，比如在学校教务系统中，HeadMaster一旦注意到有新的学生信息被保存成功时，就会调用sendMail方法发送一封邮件到校长的邮箱中，我们把诸如此类的动作称为后继动作。对于观察者而言，其后继动作可以分为两类：基于“推数据”的后继动作和基于“拉数据”的后继动作。
   A.推数据
    所谓“推数据”，即当被观察对象发生变化时，它将把相关的变化数据以参数的形式传给被观察者。比如，在学校教务系统的观察者模式中，我们使用的就是基于“推数据”的后继动作。当StudentBean的当前对象被保存到数据库后，该对象将作为参数被传入到update方法中，作为观察者的HeadMaster将从update方法的参数中得到需要的数据，形象一点来说，数据是由被观察者“推”给观察者的。

       基于“推数据”的后继动作的优点在于观察者一方无需考虑数据是如何得到的，只需对得到的数据进行相应的处理即可。此时，观察者与被观察者之间几乎没有什么耦合。

基于“推数据”的后继动作的缺点在于观察者获得数据的形式是被动的，对于同一个观察对象而言，不同观察者想要获得的数据很有可能是不同的，但此时他们将不得不接受由参数传入的一些与自己没有关系的数据。比如，在学校教务系统中，校长可能只想得到学生的学历信息，而教务主任只想得到学生的交费信息，但他们将不得不接受一些与己无关的额外信息。此外，若方法update的参数发生变化也会对不同观察者的后继动作造成一些影响。
    B.拉数据
    所谓“拉数据”，即当被观察对象发生变化时，不是由被观察者把数据传给观察者，而是由观察者主动到被观察对象中来取得数据。形象一点来说，数据是由观察者主动到被观察者中来“拉” 的。当然，此时在被观察的对象或接口中需要提供一些方法来供观察者“拉”，同时在观察者对象中也需提供一个对被观察对象的引用的属性，由此也造成了观察者与被观察者之间一定程度的耦合。

观察者模式的效果有以下几个优点：

       （1）观察者模式在被观察者和观察者之间建立一个抽象的耦合。被观察者角色所知道的只是一个具体现察者聚集，每一个具体现察者都符合一个抽象观察者的接口。被观察者并不认识任何一个具体观察者，它只知道它们都有一个共同的接口。由于被观察者和观察者没有紧密地耦合在一起，因此它们可以属于不同的抽象化层次。

       （2）观察者模式支持广播通信。被观察者会向所有的登记过的观察者发出通知。
 观察者模式有下面的一些缺点：

       （1）如果一个被观察者对象有很多直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。

       （2）如果在被观察者之间有循环依赖的话，被观察者会触发它们之间进行循环调用，导致系统崩溃。在使用观察考模式时要特别注意这一点。

       （3）如果对观察者的通知是通过另外的线程进行异步投递的话，系统必须保证投递是以自恰的方式进行的。

       （4）虽然观察者模式可以随时使观察者知道所观察的对象发生了变化，但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化的。

 命令（Command）模式属于对象的行为模式【GOF95】。命令模式又称为行动（Action）模式或交易（Transaction）模式。命令模式把一个请求或者操作封装到一个对象中。命令模式允许系统使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。 命令模式是对命令的封装。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。 每一个命令都是一个操作：请求的一方发出请求要求执行一个操作；接收的一方收到请求，并执行操作。命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。
  宏命令也是一个具体的命令,只不过他调用了一个或多个其它命令,因此执行一个命令时就相当于执行多个命令.

 二、 命令模式的结构 命令模式的类图如下： 

命令模式涉及到五个角色，它们分别是：   

• 命令（Command）角色：声明了一个给所有具体命令类的抽象接口。这是一个抽象角色。  
• 具体命令（ConcreteCommand）角色：定义一个接受者和行为之间的弱耦合；实现 Execute()方法，负责调用接收考的相应操作。Execute()方法通常叫做执方法。  
• 请求者（Invoker）角色：负责调用命令对象执行请求，相关的方法叫做行动方法。  
• 接收者（Receiver）角色：负责具体实施和执行一个请求。任何一个类都可以成为接收者，实施和执行请求的方法叫做行动方法。 

三、 玉帝传美猴王上天

 命令模式不是新的发明，在美猴王大闹天宫之前就有了。那时玉帝命令太白金星召美猴王上天："金星径入(水帘洞)当中，面南立定道：'我是西方太白金星，奉玉帝招安圣旨，下界请你上大，拜受仙录。'"玉帝是系统的客户端，太白金星是命令的发出者，猴王是命令的接收者，圣旨就是命令。玉帝的这一道命令就是要求猴王到上界报到。玉帝只管发出命令，而不管命令是怎样传达到美猴王的。太白金星负责将圣旨传到，可是美猴王怎么执行圣旨、何时执行圣旨是美猴王自己的事。果不然，不久美猴王就大闹了天宫。 这个模拟系统的设计如下： 

四、 命令模式的实现

 首先命令应当"重"一些还是"轻"一些。在不同的情况下，可以做不同的选择。如果把命令设计得"轻"，那么它只是提供了一个请求者和接收者之间的耦合而己，命令代表请求者实现请求。相反，如果把命令设计的"重"，那么它就应当实现所有的细节，包括请求所代表的操作，而不再需要接收者了。当一个系统没有接收者时，就可以采用这种做法。 更常见的是处于最"轻"和最"重"的两个极端之间时情况。命令类动态地决定调用哪一个接收者类。 

其次是否支持undo和 redo。如果一个命令类提供一个方法，比如叫 unExecute()，以恢复其操作的效果，那么命令类就可以支持undo 和 redo。具体命令类需要存储状态信息，包括： 

1. 接收者对象实际上实施请求所代表的操作； 

2. 对接收者对象所作的操作所需要的参数； 

3. 接收者类的最初的状态。接收者必须提供适当的方法，使命令类可以通过调用这个方法，以便接收者类恢复原有状态。

 如果只需要提供一层的 undo和 redo，那么系统只需要存储最后被执行的那个命令对象。如果需要支持多层的 undo 和redo，那么系统就需要存储曾经被执行过的命令的清单，清单能允许的最大的长度便是系统所支持的undo 和 redo的层数。沿着清单逆着执行清单上的命令的反命令（unExecute()）便是 undo；沿着清单顺着执行清单上的命令便是 redo。

五、 在什么情况下应当使用命令模式

 在下面的情况下应当考虑使用命令模式：

•  1、使用命令模式作为"CallBack"在面向对象系统中的替代。"CallBack"讲的便是先将一个函数登记上，然后在以后调用此函数。 
• 2、需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命期。换言之，原先的请求发出者可能已经不在了，而命令对象本身仍然是活动的。这时命令的接收者可以是在本地，也可以在网络的另外一个地址。命令对象可以在串行化之后传送到另外一台机器上去。 
• 3、系统需要支持命令的撤消(undo)。命令对象可以把状态存储起来，等到客户端需要撤销命令所产生的效果时，可以调用 undo()方法，把命令所产生的效果撤销掉。命令对象还可以提供 redo()方法，以供客户端在需要时，再重新实施命令效果。 
• 4、如果一个系统要将系统中所有的数据更新到日志里，以便在系统崩溃时，可以根据日志里读回所有的数据更新命令，重新调用 Execute()方法一条一条执行这些命令，从而恢复系统在崩溃前所做的数据更新。
• 5、一个系统需要支持交易(Transaction)。一个交易结构封装了一组数据更新命令。使用命令模式来实现交易结构可以使系统增加新的交易类型。