设为首页收藏本站
开启辅助访问

在路上

 找回密码
 立即注册
在路上 › 站点首页 ›学习 › 查看内容

解析Java设计模式编程中命令模式的使用

2016-8-29 13:11| 发布者: zhangjf| 查看: 523| 评论: 0

摘要: 定义：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。 类型：行为类模式 类图： 命令模式的结构 顾名思义，命令模式就是 ...

定义：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
类型：行为类模式
类图：

201621695208910.jpg (589×247)

命令模式的结构
 顾名思义，命令模式就是对命令的封装，首先来看一下命令模式类图中的基本结构：
Command类：是一个抽象类，类中对需要执行的命令进行声明，一般来说要对外公布一个execute方法用来执行命令。
ConcreteCommand类：Command类的实现类，对抽象类中声明的方法进行实现。
Client类：最终的客户端调用类。
以上三个类的作用应该是比较好理解的，下面我们重点说一下Invoker类和Recevier类。
Invoker类：调用者，负责调用命令。
Receiver类：接收者，负责接收命令并且执行命令。
所谓对命令的封装，说白了，无非就是把一系列的操作写到一个方法中，然后供客户端调用就行了，反映到类图上，只需要一个ConcreteCommand类和Client类就可以完成对命令的封装，即使再进一步，为了增加灵活性，可以再增加一个Command类进行适当地抽象，这个调用者和接收者到底是什么作用呢？
其实大家可以换一个角度去想：假如仅仅是简单地把一些操作封装起来作为一条命令供别人调用，怎么能称为一种模式呢？命令模式作为一种行为类模式，首先要做到低耦合，耦合度低了才能提高灵活性，而加入调用者和接收者两个角色的目的也正是为此。
例子:
模拟对电视机的操作有开机、关机、换台命令。代码如下

  2. //执行命令的接口
  3. public interface Command {
  4. 　　void execute();
  5. }
  7. //命令接收者Receiver
  8. public class Tv {
  9. 　　public int currentChannel = 0;
  11. 　　public void turnOn() {
  12. 　　 System.out.println("The televisino is on.");
  13. 　　}
  15. 　　public void turnOff() {
  16. 　　 System.out.println("The television is off.");
  17. 　　}
  19. 　　public void changeChannel(int channel) {
  20. 　　 this.currentChannel = channel;
  21. 　　 System.out.println("Now TV channel is " + channel);
  22. 　　}
  23. }
  25. //开机命令ConcreteCommand
  26. public class CommandOn implements Command {
  27. 　　private Tv myTv;
  29. 　　public CommandOn(Tv tv) {
  30. 　　 myTv = tv;
  31. 　　}
  33. 　　public void execute() {
  34. 　　 myTv.turnOn();
  35. 　　}
  36. }
  38. //关机命令ConcreteCommand
  39. public class CommandOff implements Command {
  40. 　　private Tv myTv;
  42. 　　public CommandOff(Tv tv) {
  43. 　　 myTv = tv;
  44. 　　}
  46. 　　public void execute() {
  47. 　　 myTv.turnOff();
  48. 　　}
  49. }
  51. //频道切换命令ConcreteCommand
  52. public class CommandChange implements Command {
  53. 　　private Tv myTv;
  55. 　　private int channel;
  57. 　　public CommandChange(Tv tv, int channel) {
  58. 　　 myTv = tv;
  59. 　　 this.channel = channel;
  60. 　　}
  62. 　　public void execute() {
  63. 　　 myTv.changeChannel(channel);
  64. 　　}
  65. }
  67. //可以看作是遥控器Invoker
  68. public class Control {
  69. 　　private Command onCommand, offCommand, changeChannel;
  71. 　　public Control(Command on, Command off, Command channel) {
  72. 　　 onCommand = on;
  73. 　　 offCommand = off;
  74. 　　 changeChannel = channel;
  75. 　　}
  77. 　　public void turnOn() {
  78. 　　 onCommand.execute();
  79. 　　}
  81. 　　public void turnOff() {
  82. 　　 offCommand.execute();
  83. 　　}
  85. 　　public void changeChannel() {
  86. 　　 changeChannel.execute();
  87. 　　}
  88. }
  90. //测试类Client
  91. public class Client {
  92. 　　public static void main(String[] args) {
  93. 　　 // 命令接收者Receiver
  94. 　　 Tv myTv = new Tv();
  95. 　　 // 开机命令ConcreteCommond
  96. 　　 CommandOn on = new CommandOn(myTv);
  97. 　　 // 关机命令ConcreteCommond
  98. 　　 CommandOff off = new CommandOff(myTv);
  99. 　　 // 频道切换命令ConcreteCommond
  100. 　　 CommandChange channel = new CommandChange(myTv, 2);
  101. 　　 // 命令控制对象Invoker
  102. 　　 Control control = new Control(on, off, channel);
  104. 　　 // 开机
  105. 　　 control.turnOn();
  106. 　　 // 切换频道
  107. 　　 control.changeChannel();
  108. 　　 // 关机
  109. 　　 control.turnOff();
  110. 　　}
  111. }
复制代码

执行结果

  2. The televisino is on.
  3. Now TV channel is 2
  4. The television is off.
复制代码

命令模式的优缺点
 首先，命令模式的封装性很好：每个命令都被封装起来，对于客户端来说，需要什么功能就去调用相应的命令，而无需知道命令具体是怎么执行的。比如有一组文件操作的命令：新建文件、复制文件、删除文件。如果把这三个操作都封装成一个命令类，客户端只需要知道有这三个命令类即可，至于命令类中封装好的逻辑，客户端则无需知道。
其次，命令模式的扩展性很好，在命令模式中，在接收者类中一般会对操作进行最基本的封装，命令类则通过对这些基本的操作进行二次封装，当增加新命令的时候，对命令类的编写一般不是从零开始的，有大量的接收者类可供调用，也有大量的命令类可供调用，代码的复用性很好。比如，文件的操作中，我们需要增加一个剪切文件的命令，则只需要把复制文件和删除文件这两个命令组合一下就行了，非常方便。
最后说一下命令模式的缺点，那就是命令如果很多，开发起来就要头疼了。特别是很多简单的命令，实现起来就几行代码的事，而使用命令模式的话，不用管命令多简单，都需要写一个命令类来封装。

命令模式的适用场景
 对于大多数请求-响应模式的功能，比较适合使用命令模式，正如命令模式定义说的那样，命令模式对实现记录日志、撤销操作等功能比较方便。

总结
 对于一个场合到底用不用模式，这对所有的开发人员来说都是一个很纠结的问题。有时候，因为预见到需求上会发生的某些变化，为了系统的灵活性和可扩展性而使用了某种设计模式，但这个预见的需求偏偏没有，相反，没预见到的需求倒是来了不少，导致在修改代码的时候，使用的设计模式反而起了相反的作用，以至于整个项目组怨声载道。这样的例子，我相信每个程序设计者都遇到过。所以，基于敏捷开发的原则，我们在设计程序的时候，如果按照目前的需求，不使用某种模式也能很好地解决，那么我们就不要引入它，因为要引入一种设计模式并不困难，我们大可以在真正需要用到的时候再对系统进行一下，引入这个设计模式。
拿命令模式来说吧，我们开发中，请求-响应模式的功能非常常见，一般来说，我们会把对请求的响应操作封装到一个方法中，这个封装的方法可以称之为命令，但不是命令模式。到底要不要把这种设计上升到模式的高度就要另行考虑了，因为，如果使用命令模式，就要引入调用者、接收者两个角色，原本放在一处的逻辑分散到了三个类中，设计时，必须考虑这样的代价是否值得。

收藏 邀请
上一篇：实例讲解Java的Spring框架中的控制反转和依赖注入下一篇：浅析Java中的访问控制权限

最新评论

相关分类

小黑屋|在路上 ( 蜀ICP备15035742号-1 )  

;

GMT+8, 2025-7-1 14:24

Copyright 2015-2025 djqfx

返回顶部