23 Design Modes (9): Command mode __ design mode

One: the definition of command mode
---> Command mode is a highly cohesive mode.
---> Encapsulates a request into an object, allowing you to parameterize clients using different requests, queuing up requests, or logging request logs, which provides the ability to undo and restore commands.
---> Command-mode roles
Receive receiver role ==> the role is the role of the work, the command passed here should be executed
Command command role ==> all commands that need to be executed are declared here
The Invoker caller role ==> receives the command and executes the command.
---> Command mode is simpler, but it is used very frequently in the project, because its encapsulation is very good, separates the requester (Invoker) and the performer (Receiver), extensibility also has the very good safeguard, the common code is relatively simple


Second: The Application of command mode

Advantages of the "1" Command mode
Decoupling between classes
There is no dependency between the--> caller role and the receiver role, and the caller implements the function by simply invoking the Execute method of the command abstract class, without having to know exactly which recipient is executing.
Scalability
-->command subclasses can be extended very easily, while caller Invoker and high-level module client do not produce serious code coupling.
Command mode combined with other modes will be more excellent
The--> command mode can combine the responsibility chain pattern to realize the command family parsing task, and the template method pattern can reduce the expansion of command subclass.

Disadvantages of the "2" command pattern
--> Command mode is also flawed, see command subclass: If there are n commands, the problem comes out, the command subclass is not a few, but N, this class expands very large, this requires the reader in the project carefully consider using.


Three: Usage Scenarios for Command mode
--> as long as you think it is the command of the place can use the command mode, for example, in the GUI development, a button click is a command, you can use command mode, the simulation of DOS commands, of course, to use command mode; trigger-feedback mechanism processing, etc.


IV: Best Practices
---> It does simplify a lot, each command completes a single function, rather than fulfilling different responsibilities according to the receiver.

V: Cases

"1" Command abstract class

Package com.yeepay.sxf.template10;
/**
 * Abstract Command class
 * @author sxf
 * * *
/Public abstract class Command {
    //each command class must have a method
    to execute the command public abstract void execute ();
}

"2" Specific command Class 1

Package com.yeepay.sxf.template10;
/**
 * Defines two specific command classes that the reader can extend in practical applications.
 * In each command class, the pass constructor defines which recipient the command is issued for, and defines the body that the command receives.
 * The caller is very simple, only the delivery of the command,
 * @author SXF * * */Public
class ConcreteComand1 extends command{
    //Receiver
    private Receiver Receiver;
    
    Constructor public
    ConcreteComand1 (Receiver Receiver) {
        this.receiver=receiver;
    }
    You must implement a command
    @Override public
    Void execute () {
        this.receiver.doSomething ();    
    }

}

"3" Specific command Class 2

Package com.yeepay.sxf.template10;


/**
 * Receive command
 * @author SXF
 *
 *
/public class ConcreteComand2 extends command {
    //receiver
    Private Receiver Receiver;
    Constructor public
    ConcreteComand2 (Receiver Receiver) {
        this.receiver=receiver;
    }
    You must implement a command
    @Override public
    Void execute () {
        this.receiver.doSomething ();
    }

    
}

"4" Receive Class (True performer) abstract class

Package com.yeepay.sxf.template10;
/** *
 Abstract receiver *
 @author sxf
 * Very strange, why receiver is an abstract class?
 * That is because the receiver can have more than one, and there is more than one need to define an abstract set of all attributes--the recipient of abstraction,
 * */public abstract
class Receiver {
    //abstract receiver, Defines the business public
    abstract void dosomething () that each recipient must complete;

"5" true performer 1

Package com.yeepay.sxf.template10;
/**
 * Receiver 1
 * @author SXF
 * * */public
class ConcreteReciver1 extends receiver{

    @Override Public
    void DoSomething () {
        System.out.println ("concretereciver1.dosomething () I want to log on to Earth");
    }

    

"6" true performer 2

Package com.yeepay.sxf.template10;
/**
 * Receiver 2
 * @author SXF
 * * */public
class ConcreteReciver2 extends Receiver {

    @Override Public
    void DoSomething () {
        System.out.println ("concretereciver2.dosomething (I want to log on to Mars)");
    }

"7" Caller

Package com.yeepay.sxf.template10;
/**
 * Caller
 is like a doormat, no matter what command, to receive, execute!
 * @author SXF
 * * *
/public class Invoker {
    /**
     * Command class
    /private commands command;
    /**
     * doormat, receive commands
     * @param command
     /public
    void SetCommand (Command command) {
        this.command= command;
    /**
     * Execute command */public
    Void action () {
        this.command.execute ();
    }
}

"8" Client

Package com.yeepay.sxf.template10;
/**
 * Client class
 * @author sxf
 * * *
/public class Client {public

    static void Main (string[] args) {
        ///First declare the caller invoker
        invoker invoker = new Invoker ();
        Defines a recipient
        Receiver receiver=new ConcreteReciver1 ();
        Define a command to send to the receiver.
        Command command=new ConcreteComand1 (receiver);
        Give the order to the caller to execute
        invoker.setcommand (command);
        Execute command
        invoker.action ();
        
    }

The original text is reproduced in http://www.cnblogs.com/shangxiaofei/p/5131610.html