Command pattern for design mode (behavioral)

PS One sentence: Eventually choose Csdn to organize the publication of the knowledge points of these years, the article parallel migration to CSDN. Because CSDN also support markdown grammar, Ah!

"Craftsman Joshui Http://blog.csdn.net/yanbober" read the previous "design pattern (behavioral) Strategy model (strategy pattern)" Http://blog.csdn.net/yanbober/article /details/45498567

Overview

In software development, we often need to send a request to some object (call one or some of these methods), but do not know who the recipient of the request is, and we do not know what the requested operation is, at this time, we specifically want to be able to design the software in a loosely coupled manner, Enables the request sender and the requesting receiver to eliminate the coupling between each other, making the call relationship between the objects more flexible, with the flexibility to specify the request receiver and the requested operation. The command pattern provides a perfect solution for this type of problem. The command pattern can completely decouple the request sender from the receiver, and there is no direct reference between the sender and the recipient, and the object sending the request needs only to know how to send the request, without having to know how to complete the request.

Core

concept: encapsulates a request as an object, allowing us to parameterize the customer with different requests, queue requests or log requests, and support revocable operations. The command pattern is an object-oriented pattern with an alias of Action (action) mode or transaction (Transaction) mode.

Command mode structure important core modules:

Command (Abstract command Class)

An abstract command class is generally an abstract class or interface in which the Execute () method used to execute the request is declared, through which the related actions of the requesting receiver can be invoked.

Concretecommand (Specific command Class)

A specific command class is a subclass of an abstract command class that implements a method declared in an abstract command class that corresponds to a specific recipient object and binds the action of the recipient object. When the Execute () method is implemented, the associated Action (action) of the recipient object is invoked.

Invoker (caller)

The caller is the request sender, which executes the request through the Command object. A caller does not need to determine its recipient at design time, so it only has an association with the abstract Command class. You can inject a specific command object into it while the program is running, and then invoke the Execute () method of the specific command object to implement an indirect call to the request recipient.

Receiver (receiver)

The recipient performs the action associated with the request, which specifically implements the business processing of the request.

Usage Scenarios

The system needs to decouple the requesting caller from the request receiver so that the caller and receiver do not interact directly. The caller does not need to know the recipient's presence, nor does it need to know who the recipient is, nor does the receiver care when it is called.

The system needs to specify requests and execute requests at different times. A Command object and the initial caller of the request can have different lifetimes, in other words, the original request issuer may already be gone, and the command object itself is still active, the command object can be invoked to invoke the request recipient, without the need to care about the existence of the requesting caller, you can request the log file and other mechanisms to achieve concrete implementation.

The system needs to support the undo (undo) operation and Recovery (Redo) operation of the command.

The system needs to combine a set of actions to form a macro command.

Program Ape Instance

Here is a simple example of the most basic command pattern, not many explanations:

 PackageYanbober.github.io;//command (Abstract command Class)Interface Command {voidexec ();}//concretecommand (Specific command Class)Class Concretecommand implements Command {@Override     Public void exec() {Receiver receiver =NewReceiver ();    Receiver.action (); }}//invoker (caller)Class Invoker {Privatecommand command; Public Invoker(Command command) { This. command = command; } Public void SetCommand(Command command) { This. command = command; } Public void calling() {if(Command! =NULL) {command.exec (); }    }}//receiver (recipient)Class Receiver { Public void Action() {System.out.println ("I ' m bei called!"); }}//Client Public  class Main {     Public Static void Main(string[] args) {Invoker Invoker =NewInvoker (NewConcretecommand ());    Invoker.calling (); }}

sum up a

Command mode Advantages:

Reduce the coupling degree of the system.

New commands can be easily added to the system. Since adding new specific command classes does not affect other classes, it is easy to add new specific command classes without modifying the original system source code, or even the customer class code, to meet the "open and close principle" requirements.

It is easier to design a command queue or a macro command (a combo command).

Provides a design and implementation scenario for the request revocation (undo) and Recovery (Redo) operations.

Command mode disadvantages:

Using command mode may cause some systems to have too many specific command classes. Because there is a need to design a specific command class for each invocation of the request recipient, it may be necessary to provide a large number of specific command classes in some systems, which will affect the use of the command pattern.

"Craftsman Joshui Http://blog.csdn.net/yanbober" Continue reading "to be continued ... 》

Command pattern for design mode (behavioral)