Java命令设计模式详解

将来自客户端的请求传入一个对象,从而使你可用不同的请求对客户进行参数化。用于“行为请求者”与“行为实现者”解耦,可实现二者之间的松耦合,以便适应变化。分离变化与不变的因素。

一、角色
Command
定义命令的接口,声明执行的方法。
ConcreteCommand
命令接口实现对象,是“虚”的实现;通常会持有接收者,并调用接收者的功能来完成命令要执行的操作。
Receiver
接收者,真正执行命令的对象。任何类都可能成为一个接收者,只要它能够实现命令要求实现的相应功能。
Invoker
要求命令对象执行请求,通常会持有命令对象,可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方,也就是说相当于使用命令对象的入口。
Client
创建具体的命令对象,并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端,而是在组装命令对象和接收者,或许,把这个Client称为装配者会更好理解,因为真正使用命令的客户端是从Invoker来触发执行。

二、优点

  • 1.降低对象之间的耦合度。
  • 2.新的命令可以很容易地加入到系统中。
  • 3.可以比较容易地设计一个组合命令。
  • 4.调用同一方法实现不同的功能

三、缺点
使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个命令都需要设计一个具体命令类,因此某些系统可能需要大量具体命令类,这将影响命令模式的使用。

四、适用情况

  • 系统需要将请求调用者和请求接收者解耦,使得调用者和接收者不直接交互。
  • 系统需要在不同的时间指定请求、将请求排队和执行请求。
  • 系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。
  • 系统需要将一组操作组合在一起,即支持宏命令。

五、应用
模拟对电视机的操作有开机、关机、换台命令。代码如下

//执行命令的接口
public interface Command {
  void execute();
}
//命令接收者Receiver
public class Tv {
  public int currentChannel = 0; 

  public void turnOn() {
   System.out.println("The televisino is on.");
  } 

  public void turnOff() {
   System.out.println("The television is off.");
  } 

  public void changeChannel(int channel) {
   this.currentChannel = channel;
   System.out.println("Now TV channel is " + channel);
  }
}
//开机命令ConcreteCommand
public class CommandOn implements Command {
  private Tv myTv; 

  public CommandOn(Tv tv) {
   myTv = tv;
  } 

  public void execute() {
   myTv.turnOn();
  }
}
//关机命令ConcreteCommand
public class CommandOff implements Command {
  private Tv myTv; 

  public CommandOff(Tv tv) {
   myTv = tv;
  } 

  public void execute() {
   myTv.turnOff();
  }
}
//频道切换命令ConcreteCommand
public class CommandChange implements Command {
  private Tv myTv; 

  private int channel; 

  public CommandChange(Tv tv, int channel) {
   myTv = tv;
    this.channel = channel;
  } 

  public void execute() {
   myTv.changeChannel(channel);
  }
}
//可以看作是遥控器Invoker
public class Control {
  private Command onCommand, offCommand, changeChannel; 

  public Control(Command on, Command off, Command channel) {
    onCommand = on;
    offCommand = off;
   changeChannel = channel;
  } 

  public void turnOn() {
   onCommand.execute();
  } 

  public void turnOff() {
   offCommand.execute();
  } 

  public void changeChannel() {
    changeChannel.execute();
  }
}
//测试类Client
public class Client {
  public static void main(String[] args) {
    // 命令接收者Receiver
    Tv myTv = new Tv();
    // 开机命令ConcreteCommond
    CommandOn on = new CommandOn(myTv);
    // 关机命令ConcreteCommond
    CommandOff off = new CommandOff(myTv);
    // 频道切换命令ConcreteCommond
    CommandChange channel = new CommandChange(myTv, 2);
    // 命令控制对象Invoker
   Control control = new Control(on, off, channel); 

    // 开机
    control.turnOn();
    // 切换频道
    control.changeChannel();
    // 关机
    control.turnOff();
  }
}

执行结果
The televisino is on. 
Now TV channel is 2 
The television is off. 

六、总结
1.命令模式的本质是对命令进行封装,将发出命令的责任和执行命令的责任分割开。
2.每一个命令都是一个操作:请求的一方发出请求,要求执行一个操作;接收的一方收到请求,并执行操作。
3.命令模式允许请求的一方和接收的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否被执行、何时被执行,以及是怎么被执行的。
4.命令模式使请求本身成为一个对象,这个对象和其他对象一样可以被存储和传递。
5.命令模式的关键在于引入了抽象命令接口,且发送者针对抽象命令接口编程,只有实现了抽象命令接口的具体命令才能与接收者相关联。

以上就是关于Java命令设计模式的详细介绍,希望对大家的学习有所帮助。

(0)

相关推荐

  • 举例说明Java设计模式编程中ISP接口隔离原则的使用

    Interface Segregation Principle,ISP接口隔离原则主张使用多个专门的接口比使用单一的总接口要好. 一个类对另外一个类的依赖性应当是建立在最小的接口上的. 一个接口代表一个角色,不应当将不同的角色都交给一个接口.没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染. "不应该强迫客户依赖于它们不用的方法.接口属于客户,不属于它所在的类层次结构."这个说得很明白了,再通俗点说,不要强迫客户使用它们不用的方法,如果强迫用户使用它们不使用的方法

  • 理解Java设计模式编程中的迪米特原则

    定义:一个对象应该对其他对象保持最少的了解. 问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大. 解决方案:尽量降低类与类之间的耦合.          自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚.无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率.低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的.          迪米特法则又叫最少知道原则,最早是在1987年

  • 详解Java设计模式编程中的依赖倒置原则

    定义: 高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率.          依赖倒置原则基于这样一个事实:

  • 详解Java的设计模式编程中的原型模式

    定义:用原型实例指定创建对象的种类,并通过拷贝这些原型创建新的对象. 类型:创建类模式 类图: 原型模式主要用于对象的复制,它的核心是就是类图中的原型类Prototype.Prototype类需要具备以下两个条件: 实现Cloneable接口.在java语言有一个Cloneable接口,它的作用只有一个,就是在运行时通知虚拟机可以安全地在实现了此接口的类上使用clone方法.在java虚拟机中,只有实现了这个接口的类才可以被拷贝,否则在运行时会抛出CloneNotSupportedExcepti

  • 详解Java设计模式编程中的里氏替换原则

    定义1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型. 定义2:所有引用基类的地方必须能透明地使用其子类的对象. 问题由来:有一功能P1,由类A完成.现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成.新功能P由类A的子类B来完成,则子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障. 解决方

  • 简单理解遵循接口隔离原则的Java设计模式编程

    定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: 这个图的意思是:类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现.类C依赖接口I中的方法1.方法4.方法5,类D是

  • 解析Java编程中设计模式的开闭原则的运用

    开闭原则(Open Closed Principle)是Java世界里最基础的设计原则,它指导我们如何建立一个稳定的.灵活的系统. 定义: 一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. Softeware entities like classes,modules and functions should be open for extension but closed for modifications. 开闭原则的含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有代码

  • 实例讲解Java设计模式编程中的OCP开闭原则

    定义:一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. 问题由来:在软件的生命周期内,因为变化.升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试. 解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化.          开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定灵活的系统.开闭原则可能是设计模式六项原则中定义最模糊的一个了,它

  • 举例解析Java的设计模式编程中里氏替换原则的意义

    里氏替换原则,OCP作为OO的高层原则,主张使用"抽象(Abstraction)"和"多态(Polymorphism)"将设计中的静态结构改为动态结构,维持设计的封闭性."抽象"是语言提供的功能."多态"由继承语义实现. 里氏替换原则包含以下4层含义: 子类可以实现父类的抽象方法,但是不能覆盖父类的非抽象方法. 子类中可以增加自己特有的方法. 当子类覆盖或实现父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更

  • Java建造者设计模式详解

    建造者模式(Builder):将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示. 使用场景: 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时. 当构造过程必须允许被构造的对象有不同的表示时. 通用类图: 举例:我们生活当中有许多设备都是以组装的形式存在的,例如台式电脑,那么有些厂商就会推出一些具有默认配置的组装电脑主机(这里可以用到模板方法模式来实现),顾客可以购买默认配置的产品,也可以要求厂商重新组装一部不同配置不同组装方式的主机.此时,我们就可以使

随机推荐