Java设计模式——命令模式

杨利霞

Java设计模式——命令模式

8 a5 f. X+ L! {3 p. W命令模式
9 L  p% V: m+ M4 U- N+ N3 Y; H
4 n; k2 C$ C2 w( F1 D+ Z- m命令模式很好理解，举个例子，司令员下令让士兵去干件事情，从整个事情的角度来考虑，司令员的作用是，发出口令，口令经过传递，传到了士兵耳朵里，士兵去执行。这个过程好在，三者相互解耦，任何一方都不用去依赖其他人，只需要做好自己的事儿就行，司令员要的是结果，不会去关注到底士兵是怎么实现的。我们看看关系图：
1 r+ F# |5 r. d+ ~0 ^% I0 p
" b3 j/ g/ b: b) h2 QInvoker是调用者（司令员），Receiver是被调用者（士兵），MyCommand是命令，实现了Command接口，持有接收对象，看实现代码：

public interface Command {  
    public void exe();  
}  
3 N! c5 I5 A; O1 |6 P1 J+ gpublic class MyCommand implements Command {  
9 N) f! {6 Z# x+ k  i
. S+ z& e0 j  f3 ]9 v. z    private Receiver receiver;  

    public MyCommand(Receiver receiver) {  
        this.receiver = receiver;  
% o6 |2 M# R" I$ K1 A9 T    }  
. ]3 C# L6 g* l6 e  v$ C' a' x
7 H/ @, Y1 j  L: H$ Y& G& I' r8 ~# a    @Override  
    public void exe() {  
        receiver.action();  
+ R# H  z/ l* ~# V7 }4 H    }  
/ S/ N# N* B8 U$ a}  
public class Receiver {  
3 a6 i+ ^: L0 X2 i% F. n    public void action(){  
6 N3 x9 H" d" b        System.out.println("command received!");  
8 P3 u0 N3 P  U8 l' o2 R0 j' u    }  
}  
public class Invoker {  
9 O# t6 |- k% f* _3 m( I/ k
& M- X3 e! ^+ s' s  }1 B    private Command command;  
+ o6 G  y) w$ Q; L! F, o
    public Invoker(Command command) {  
        this.command = command;  
    }  
$ {7 F% `1 N+ m5 ^
1 S; v/ V" \- @0 w8 Z" v0 u9 [    public void action(){  
        command.exe();  
( T/ P3 y4 V6 C* {    }  
}  
public class Test {  
) D1 Z. }0 W2 p  o
7 h1 E" I; H: f# K7 W    public static void main(String[] args) {  
. H6 W  H  P1 F: v# C        Receiver receiver = new Receiver();  
        Command cmd = new MyCommand(receiver);  
  I, y% d8 `% S; l9 w        Invoker invoker = new Invoker(cmd);  
$ M. w. {9 i* ^7 c) |( C6 L        invoker.action();  
    }  
1 o* Q% B0 g2 U8 P5 Q}  


& v8 Z+ N. v0 d: a4 }这个很哈理解，命令模式的目的就是达到命令的发出者和执行者之间解耦，实现请求和执行分开，熟悉Struts的同学应该知道，Struts其实就是一种将请求和呈现分离的技术，其中必然涉及命令模式的思想！

9 J6 X7 ]! P  a+ ?* F. Z3 p3 F介绍
* ]3 q9 O. s& v5 c# G. r) |意图：将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。
) X) N2 a6 k% J) r0 j7 B8 z
主要解决：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。

何时使用：在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。

  P9 V, C- g3 T7 V0 s  I/ M: L8 L. U如何解决：通过调用者调用接受者执行命令，顺序：调用者→接受者→命令。
  O. r6 e7 A$ ^
关键代码：定义三个角色：1、received 真正的命令执行对象 2、Command 3、invoker 使用命令对象的入口
, h1 N9 r* d" `7 A! t2 l
2 u$ R4 _4 d5 r7 ^9 k7 d应用实例：struts 1 中的 action 核心控制器 ActionServlet 只有一个，相当于 Invoker，而模型层的类会随着不同的应用有不同的模型类，相当于具体的 Command。

优点： 1、降低了系统耦合度。 2、新的命令可以很容易添加到系统中去。

缺点：使用命令模式可能会导致某些系统有过多的具体命令类。
2 A1 y1 l: L- p' ?9 @
使用场景：认为是命令的地方都可以使用命令模式，比如： 1、GUI 中每一个按钮都是一条命令。 2、模拟 CMD。

注意事项：系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作，也可以考虑使用命令模式，见命令模式的扩展。
————————————————
版权声明：本文为CSDN博主「No_Game_No_Life_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/No_Game_No_Life_/article/details/85989272

- w/ {6 @6 l6 O( M% j  S; C! G
3 J4 N/ g1 Y5 ~- y- _) }5 Z