设计模式--命令模式

      命令模式其实和策略模式相似，都是将实现与调用解耦.
     类图：
     
     而命令模式只是更形象的模拟了实现者和调用者之间的关系。来看下一般情况下：
     
      如果我们需要实现一个订餐的程序，一般简单的想法就是一个顾客类，一个服务员，一个厨师类。调用的情况一般可以理解为由顾客类调用服务员的点餐方法，而服务员的点餐方法又调用了厨师的烧菜方法，你会发现，这就出现了耦合的问题，依赖于实现编程了。所以该如何去改呢？
     其实现在想想设计模式的核心思想就是一个词----抽象！！！！
     我们需要将这个三个类之间抽象出来，是他们之间不相互依赖于各自的实现，而是依赖于各自的抽象接口。从这点出发，就引出了commad模式，其实就是在三者之间分别建立命令抽象接口，以达到解耦的目的。
     
     命令模式思想：
     Command命令模式是一种对象行为型模式，它主要解决的问题是：在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”的问题
     是将实现者分装在一个类中，这个类一般就取名command类，随后通过这个command类进行调用者于实现者之间的联系。
     现在我们就看看，在客户点餐的过程中如何使用命令模式
     
      

class clientorder
{
public:
    clientorder();
    ~clientorder();

    void setorder(cookcommand* cook);
};

 客户类，里面有一个订餐的接口，但是这个订餐的接口需要的是抽象的command类

class cookcommand
{
public:
    cookcommand(){}
    ~cookcommand(){}

    virtual void excute() = 0;
};

commad类就是所谓的抽象层，用于调用实现者的功能。
接下来看下实现者是如何被封装的

class chinesefood : public cookcommand
{
public:
    chinesefood(){}
    ~chinesefood(){}

    void excute()
    {
        printf("cook chinese food\n");
    }
};

其实实现者有可能是别的独有的类，这时就要用到组合的模式将实现者对象包含在分装类中（继承当然也可以，但是设计模式中推荐少用继承，多用组合：P）

这样就会发现，调用者和实现这分离了，点餐的顾客不需要知道厨师是怎么做菜的，只要知道自己想吃什么菜，命令厨师去做就可以了

int _tmain(int argc, _TCHAR* argv[])
{
    clientorder client;
    client.setorder(new westfood());
    client.setorder(new chinesefood());
    system("pause");
    return 0;
}

看到没有，命令模式的实现方法和策略模式是很相似的，只不过策略模式是偏好于方法的抽象封装，而命令模式是对于实现类的封装，不过我感觉大体上还是差不多的