I understand the design pattern (C ++ implementation) -- Command pattern)

Overview:

We went to the restaurant for dinner. We ordered food via a waiter. We didn't know who made the food or when they finished it. Abstract: The "menu requestor" we and the "menu implementer" chefs are loosely coupled. We have other requests for these dishes, such as "undo, redo, we do not know who is doing this. In fact, this is the command mode described in this article.

Encapsulate a request as an object so that you can parameterize the customer with different requests, queue requests or record request logs, and support unrecoverable operations. [Gof design patterns]

Class Diagram and instance:

Role purpose:

Client) Role: Creates a concretecommand object and determines its receiver.

Command) Role: Declares an abstract interface for all specific command classes. This is an abstract role.

Specific command (concretecommand) Role: Defines the weak coupling between a receiver and a behavior; implements the execute () method, which is responsible for calling the corresponding operations of the acceptance test. The execute () method is usually called the execution method.

Invoker) Role: Calls command objects to execute requests. The related methods are called Action methods.

Receiver) Role: Implements and executes a request. Any class can be the receiver. The method for implementing and executing requests is called the action method.

Instance:

# Include <iostream >#include <vector> using namespace STD; // class roastcook {public: void makemutton () {cout <"roast mutton" <Endl ;} void makechickenwing () {cout <"roast chicken wings" <Endl ;};// abstract command class command {public: Command (roastcook * temp) {worker ER = temp;} virtual void executecmd () = 0; protected: roastcook * worker er;}; // class makemuttoncmd: Public command {public: makemuttoncmd (roastcook * temp): Command (temp) {} virtual void executecmd () {javaser-> makemutton () ;}; // class makechickenwingcmd: Public command {public: makechickenwingcmd (roastcook * temp): Command (temp) {} virtual void executecmd () {Cycler-> makechickenwing () ;}; // waiter class waiter {public: void setcmd (command * temp); // notification execution void notify (); protected: vector <command *> m_commandlist;}; void WAITER: setcmd (command * temp) {M _ Commandlist. push_back (temp); cout <"add order" <Endl;} void WAITER: Notify () {vector <command *>: iterator it; for (IT = m_commandlist.begin (); it! = M_commandlist.end (); ++ it) {(* It)-> executecmd () ;}} int main () {// roastcook * Cook = new roastcook (); command * cmd1 = new makemuttoncmd (Cook ); command * cmd2 = new makechickenwingcmd (Cook); Waiter * girl = new waiter (); // a la carte girl-> setcmd (cmd1); girl-> setcmd (cmd2 ); // The waiter notifies girl-> Policy (); Return 0 ;}

Results and implementation highlights:

1. The fundamental purpose of the command mode is to decouple "behavior requestor" from "behavior implementer". In object-oriented languages, a common implementation method is "abstract behavior as an object ".

2. The specific command object concretecommand that implements the command interface may save some additional status information as needed.

3. By using the compmosite mode, you can encapsulate multiple commands into a "composite command" macrocommand.

4. The command mode is similar to the delegate mode in C. However, there is a difference between the two defined behavior interface specifications: Command defines behavior interface specifications with "interface-Implementation" in the object-oriented model, which is stricter and more in line with abstract principles; delegate defines behavior interface specifications using function signatures, which is more flexible, but has weak abstraction capabilities.

5. Using the command mode will cause some systems to have too many specific command classes. Some systems may need dozens, hundreds, or even thousands of specific command classes, which will make the command mode impractical in such systems.

Applicability:

The command mode should be considered in the following situations:

1. Use the command mode as an alternative to "Callback" in the object-oriented system. "Callback" refers to registering a function and then calling it later.

2. You must specify the request at different times and queue the request. A command object and the original request sender can have different lifecycles. In other words, the original request sender may no longer exist, and the command object itself is still active. At this time, the command receiver can be local or another address on the network. The command object can be transmitted to another machine after being serialized.

3. The system must support undo commands ). The command object can store the status. When the client needs to revoke the effect of the command, it can call the Undo () method to cancel the effect of the command. The command object can also provide the Redo () method for the client to re-execute the command when needed.

4. if a system updates all the data in the system to the log, you can read all the data update commands in the log and call execute () again when the system crashes () to restore the data updates made by the system before the crash.

Lcl_data was originally created in csdn. Net [http://blog.csdn.net/lcl_data/article/details/9080909]

For other design patterns, see the design patterns I understand.