Introduction to Command pattern of Java design pattern

Command mode is one of the most confusing patterns for me. After reading a lot of code, I felt vaguely grasp its general principle. I think the most important way to understand the design pattern is to master the principle construction, so as to guide my actual programming. The Command pattern is actually not a very specific, prescriptive pattern, and it's this flexibility that makes it a bit confusing.

The Command definition

A lot of the code in the Command mode is graphical, it's really just a menu Command, and when we select a Command from a drop-down menu, we do some action.

Packages these commands into in a class, and then the user (caller) to the class, this is the Command pattern, in other words, the original user (caller) is a direct call these commands, such as the menu to open the document (caller), point to open the document code, directly using the Command pattern, is to add an intermediate between the two, the direct relationship between the knapp, between all the isolation at the same time, the basic no relationship.

The obvious benefit of doing this is that it conforms to the nature of encapsulation and reduces the degree of coupling. Command is a typical pattern that encapsulates behavior, and Factory is a pattern that creates encapsulation.

From the Command pattern, I also found a "common problem" with design patterns: they seemed to like to complicate simple problems, and they liked to add third parties to different classes, which, of course, made the code more robust, maintainable, and reusable.

How to use command mode

The specific Command pattern code varies, because different systems have different ways of encapsulating commands. The following example is to encapsulate the command in a List of Collection. Once any object is added to the List, it is actually loaded into a closed black box. The characteristics of the object disappear and can only be vaguely distinguished when it is taken out.

A typical Command pattern requires an interface. There is a unified method in the interface, which is "encapsulating a command/request as an object" :

public interface Command {

　　public abstract void execute ( );

}

Specific Command/request code is to implement the interface Command, the following three specific commands:

public class Engineer implements Command {

　　public void execute( ) {

　　　　//do Engineer's command

　　}

}
public class Programmer implements Command {

　　public void execute( ) {

　　　　//do programmer's command

　　}

}
public class Politician implements Command {

　　public void execute( ) {

　　　　//do Politician's command

　　}

}

As usual, we can call all three commands directly, but using the Command pattern, we wrap them up and drop them into the black box List:

public class producer{

　　public static List produceRequests() {

　　　　List queue = new ArrayList();

　　　　queue.add( new DomesticEngineer() );

　　　　queue.add( new Politician() );

　　　　queue.add( new Programmer() );

　　　　return queue;

　　}

}

After these three commands enter the List, they have lost their appearance characteristics, and when they are taken out later, they may not be able to tell who is Engineer and who is Programmer, see how to call the Command pattern below:

public class TestCommand {

　　public static void main(String[] args) {

　　　　List queue = Producer.produceRequests();

　　　　for (Iterator it = queue.iterator(); it.hasNext(); )

　　　　　　　　//
,
,
,
,
,
,
,
,

　　　　　　　　//They are at least the "sons" of the interface Command. So cast the interface Command

　　　　　　　　((Command)it.next()).execute();

　　}

}

This shows that the caller basically only interacts with the interface, not the specific implementation of the interaction, which also reflects the principle of interface-oriented programming, so that when the fourth concrete command is added later, the code in the caller's TestCommand will not have to be modified.

Understanding the core principles of the above code, in use, it should be their own method, especially in how to separate the caller and specific commands, there are many implementation methods, the above code is to use the "through the List" approach. This is just for demonstration.

A good reason to use the Command pattern is also that it implements the Undo functionality, so that each specific Command can remember the action it just performed and recover if needed.

The Command pattern is widely used in interface design. In Java, the menu commands in Swing use the Command mode. Since Java is still deficient in the performance of interface design, we will not discuss the specific code of interface design. There are many such examples on the network.