In a software system, the "behavior requestor" and "The behavior realization person" usually present a kind of "tight coupling". However, in some cases, such as "record, Undo/Redo, transaction" and so on, this can not resist the change of tight coupling is inappropriate. In this case, how do you decouple the "behavior requestor" from the "behavior-implementing Person"? Abstract a set of behaviors into objects to achieve loose coupling between them. This is the command pattern.
In Oop, everything is an object, encapsulates the request into an object, conforms to the design idea of OOP, when a client's individual request is encapsulated into an object, we can store more information about the request, make the request more capable, and the command pattern can decouple the request sender and receiver. Allows the command sender to not care about how the request will be handled.
Command:
Defines the interface of the command, declaring the method of execution.
Concretecommand:
The command interface implements the object, which is the implementation of the "virtual", usually holding the receiver and invoking the function of the receiver to complete the operation to be performed by the command.
Receiver:
Receiver, the object that actually executes the command. Any class can become a recipient, as long as it can implement the appropriate functionality that the command requires.
Invoker:
Requires the command object to execute the request, usually holding the command object, and can hold a lot of command objects. This is where the client actually triggers the command and asks the command to perform the appropriate action, which is equivalent to using the Command object's entry.
Client:
Creates a specific command object and sets the recipient of the Command object. Note that this is not our regular client, but the assembly of the Command object and the receiver, and perhaps it would be better to refer to this client as the assembler, since the client that actually uses the command is triggering execution from Invoker.
1. The essence of the command pattern is to encapsulate the command, separating the responsibility for issuing the order and the responsibility for executing the order.
2. Each command is an action: the requesting party makes a request, requests an action, the receiving party receives the request, and executes the action.
3. The command pattern allows the requesting party and the receiving party to be independent, so that the requesting party does not have to know the interface of the party receiving the request, not to know how the request was received, and whether the operation was executed, when it was executed, and how it was executed.
4. The command pattern makes the request itself an object that can be stored and passed in the same way as other objects.
5. The key to the command pattern is the introduction of an abstract command interface, and the sender is programmed for an abstract command interface, and only specific commands that implement an abstract command interface can be associated with the receiver.
Class Receiver{public: void Action () { cout<< "receiver->action" <<endl; }}; Class Command{public: virtual void Execute () = 0;}; Class Concretecommand:public Command{public: concretecommand (Receiver *preceiver): M_preceiver (preceiver) {} void Execute () { m_preceiver->action (); } Private: Receiver *m_preceiver;}; Class Invoker{public: Invoker (Command *pcommand): M_pcommand (pcommand) {} void Invoke () { m_ Pcommand->execute (); } Private: Command *m_pcommand;}; int main () { receiver *preceiver = new Receiver (); Command *pcommand = new Concretecommand (preceiver); Invoker *pinvoker = new Invoker (pcommand); Pinvoker->invoke (); Safe_delete (pinvoker); Safe_delete (pcommand); Safe_delete (preceiver); return 0;}
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
[C + + design mode] Command mode