类图:
而命令模式只是更形象的模拟了实现者和调用者之间的关系。来看下一般情况下:
如果我们需要实现一个订餐的程序,一般简单的想法就是一个顾客类,一个服务员,一个厨师类。调用的情况一般可以理解为由顾客类调用服务员的点餐方法,而服务员的点餐方法又调用了厨师的烧菜方法,你会发现,这就出现了耦合的问题,依赖于实现编程了。所以该如何去改呢?
其实现在想想设计模式的核心思想就是一个词----抽象!!!!
我们需要将这个三个类之间抽象出来,是他们之间不相互依赖于各自的实现,而是依赖于各自的抽象接口。从这点出发,就引出了commad模式,其实就是在三者之间分别建立命令抽象接口,以达到解耦的目的。
命令模式思想:
Command命令模式是一种对象行为型模式,它主要解决的问题是:在软件构建过程中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”的问题
是将实现者分装在一个类中,这个类一般就取名command类,随后通过这个command类进行调用者于实现者之间的联系。
现在我们就看看,在客户点餐的过程中如何使用命令模式
点击(此处)折叠或打开
- class clientorder
- {
- public:
- clientorder();
- ~clientorder();
- void setorder(cookcommand* cook);
- };
点击(此处)折叠或打开
- class cookcommand
- {
- public:
- cookcommand(){}
- ~cookcommand(){}
- virtual void excute() = 0;
- };
接下来看下实现者是如何被封装的
点击(此处)折叠或打开
- 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;
- }
看到没有,命令模式的实现方法和策略模式是很相似的,只不过策略模式是偏好于方法的抽象封装,而命令模式是对于实现类的封装,不过我感觉大体上还是差不多的