[设计模式]Command命令模式

command命令模式

Command模式通过将请求封装到一个对象(Command)中,并将请求的接收者存放到具体的ConcreteCommand类中的(reciver)中,从而实现调用操作的对象和操作的具体实现之间的解耦。

解析:Command模式的思想是把命令封装在一个类(Command)中,同时把接收对象也封装在一个类(Receive)中,由调用这个命令的类(Invoker)来调用。其实,如果弄清楚了Command模式的原理,就会发现其实它和注册回调函数的原理很相似,而在面向过程的设计中的回调函数其实和这里的Command类的作用是一致的。采用Command模式解耦了命令的发出者和命令的执行者。

小demo

command.h

#ifndef COMMAND_H
#define COMMAND_H

class Command
{
public:
	virtual ~Command() {}
	virtual void Execute() = 0;
};

class Receiver
{
public:
	void Action();
};

class Invoker
{
public:
	Invoker(Command *pCommand);
	~Invoker();
	void Invoke();
private:
	Command *m_pCommand;
};

class ConcreateComand	: public Command
{
public:
	ConcreateComand(Receiver* pReceiver);
	virtual ~ConcreateComand();
	virtual void Execute();
private:
	Receiver* m_pReceiver;
};

#endif

command.cpp

#include "Command.h"
#include <iostream>

void Receiver::Action()
{
	std::cout << "Receiver Action\n";
}

Invoker::Invoker(Command *pCommand)	: m_pCommand(pCommand)
{
}

Invoker::~Invoker()
{
	delete m_pCommand;
	m_pCommand = NULL;
}

void Invoker::Invoke()
{
	if (NULL != m_pCommand)
	{
		m_pCommand->Execute();
	}
}

ConcreateComand::ConcreateComand(Receiver* pReceiver): m_pReceiver(pReceiver)
{
}

main.cpp

#include "Command.h"
#include <stdlib.h>

int main()
{
	Receiver* pReceiver = new Receiver();
	Command*  pCommand  = new ConcreateComand(pReceiver);
	Invoker*  pInvoker  = new Invoker(pCommand);

	pInvoker->Invoke();
	delete pInvoker;
	system("pause");
	return 0;
}

Command模式的思想非常简单,但是Command模式也十分常见,并且威力不小。实际上,command模式关键就是提供一个抽象的command类,并将执行操作封装到command类接口中,command类中一般就只是一些接口的集合,并不包含任何的数据属性。好处有:

  • command模式将调用操作的对象和知道如何实现该操作的对象解耦在command的结构图中,Invoker对象根本就不知道具体的是哪个对象在处理Excute操作(当然要知道是Command类别的对象,也仅此而已)。
  • 在command要增加新的处理操作对象很容易,我们可以通过创建新的继承自command的子类来实现这一点。
  • command模式可以和memento模式结合起来,支持取消的操作。

实现方式

  1. 声明仅有一个执行方法的命令接口。
  2. 抽取请求并使之成为实现命令接口的具体命令类。 每个类都必须有一组成员变量来保存请求参数和对于实际接收者对象的引用。 所有这些变量的数值都必须通过命令构造函数进行初始化。
  3. 找到担任发送者职责的类。 在这些类中添加保存命令的成员变量。 发送者只能通过命令接口与其命令进行交互。 发送者自身通常并不创建命令对象, 而是通过客户端代码获取。
  4. 修改发送者使其执行命令, 而非直接将请求发送给接收者。
  5. 客户端必须按照以下顺序来初始化对象:
  • 创建接收者。
  • 创建命令, 如有需要可将其关联至接收者。
  • 创建发送者并将其与特定命令关联。

请求发送者与接收者解耦——命令模式

与其他模式的关系

责任链模式、 命令模式、 中介者模式和观察者模式用于处理请求发送者和接收者之间的不同连接方式:

  • 责任链按照顺序将请求动态传递给一系列的潜在接收者,直至其中一名接收者对请求进行处理。
  • 命令在发送者和请求者之间建立单向连接。
  • 中介者清除了发送者和请求者之间的直接连接, 强制它们通过一个中介对象进行间接沟通。
  • 观察者允许接收者动态地订阅或取消接收请求。

责任链的管理者可使用命令模式实现。

  • 在这种情况下,可以对由请求代表的同一个上下文对象执行许多不同的操作。
  • 还有另外一种实现方式, 那就是请求自身就是一个命令对象。 在这种情况下, 可以对由一系列不同上下文连接而成的链执行相同的操作。

你可以同时使用命令和备忘录模式来实现 “撤销”。 在这种情况下, 命令用于对目标对象执行各种不同的操作,备忘录用来保存一条命令执行前该对象的状态。

命令和策略模式看上去很像,因为两者都能通过某些行为来参数化对象。 但是, 它们的意图有非常大的不同。

  • 你可以使用命令来将任何操作转换为对象。 操作的参数将成为对象的成员变量。 你可以通过转换来延迟操作的执行、将操作放入队列、保存历史命令或者向远程服务发送命令等。
  • 另一方面, 策略通常可用于描述完成某件事的不同方式,让你能够在同一个上下文类中切换算法。

原型模式可用于保存命令的历史记录。

你可以将访问者模式视为命令模式的加强版本,其对象可对不同类的多种对象执行操作。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值