设计模式(11)-----命令设计模式

把命令封装成一个命令对象,使请求者和被请求者完全解耦。我们先来看一下类图:

下面我们来看代码

Invoker==SimpleRemoteControl

public
class SimpleRemoteControl {

Command slot;// 有一个插槽持有命令,而这个命令控制着设备

public SimpleRemoteControl() {

}

public
void setCommand(Command command) {

slot = command;     }

public
void buttonWasPressed() {

slot.execute();

}

}

command==Command

public
interface Command {     public
void execute();

}

concreteCommand==LightOffCommand

public
class LightOffCommand implements Command {

Light light;

public LightOffCommand(Light light) {

this.light = light;

}

public
void execute() {

light.off();

}

}

concreteCommand==LightOnCommand

public
class LightOnCommand implements Command {

Light light;

public LightOnCommand(Light light) {

this.light = light;

}

public
void execute() {

light.on();

}

}

concreteCommand==GarageDoorOpenCommand

public
class GarageDoorOpenCommand implements Command {     GarageDoor garageDoor;

public GarageDoorOpenCommand(GarageDoor garageDoor) {

this.garageDoor = garageDoor;

}

public
void execute() {

garageDoor.up();

}

}

recevier==Light

public
class Light {

public Light() {

}


}


public
void on() {

System.out.println("Light is on");

}

public
void off() {

System.out.println("Light is off");

}

client==Test

  • @说明: 不解耦的设计就是按下灯开的开关,灯开了,我按下灯灭的操作灯灭了。

  • 按下车开的开关,车开了,按下车停的操作,车停了。现在开关是两个,并且每个开关有两个命令。

*

  • 解构的设计就是我不知道我现在开关是谁的开关,你告诉我说我是灯的开关,并且是灯开的指令,我就是开灯的命名我就把灯打开了,

  • 你告诉我说是灯灭的命令,我就把灯灭了; 你告诉我说我是车的开关,我按下开关,你告诉我说开车的指令,我就开车了,你告诉我说是停车的指令我就停车了

*

  • 那解耦的设计它是如何实现的呢, 一:告诉我我是谁,并且是什么指令 1.1,有一个灯开灯灭的灯的实例 1.2,把灯传给一个一个灯开的命令对象。

  • 1.3,让后把灯开的命令对象给开关。 1.4,我按下开关等就开了。

  • 补充:这里面需要注意的地方就是开关是不知道控制谁的,定义好的固定的方法excute()

  • 好了,你先在告诉我说我现在是灯开的命令对象(LightOnCommand),那我就去灯开的命令对象里面去看一下

  • LightOnCommand.execute 到里面一看果然是灯开的指令light.on()

*

  • 二:我按下开关

*

*

  • 开关==遥控器==调用者

*

  • 我们接着再来梳理一下:

  • 站在调用者(遥控器)的角度:没给我命令之前(命令对象)我不知道我控制的是谁,我控制谁的什么命令。不想以前,上来我就确定我是灯的开关,我是车的开关。

  • 站在接受者(车,灯)的角度:我现在每一条指令都会封装成一条命令(命令对象)。不想以前,我有许多的指令在里面。

  • 站在两者解耦联系的角度:接受者封装一条命令(命名对象)给调用者,调用者确定了命令对象之后根据已经约定好的方法,去命令对象中找到这个方法,

  • 让后在到接受者中去执行相应的指令。

*

*

  • 在来捋一下,现在遥控器不知道自己是谁,也不知道自己要执行谁的什么命令,只有你告诉我我是谁,并通过约定俗成的方法调用已经知道了谁的

  • 约定俗称的方法,来确定下来我要执行什么命令。

  • 套到代码里面就是现在遥控器不知道自己是谁,也不知道要执行什么样的命令,现在你告诉我说我是灯开对象(LightOnCommand),
  • 我就根据我定义的方法(execute),去等开的对象中找一样的方法,果然够被我找到了

    (execute),这个方法告诉说去执行light.on

  • 的命令吧,我现在就把灯打开了。 所以说在命令对象中一定要有和遥控器一样的方法。这也充分发挥了面向借口编程的作用。

    *

  • 相当于以前我就知道我是灯的开关,而且一旦确定就不能变化了。不可能变成车的开关了。
    * 现在是我不知道我是谁的开关,你告诉我我是谁的开关我就是谁的开关,可以随意的切花的。

    *

  • 在这里命令模式主要就是针对的这个开关,把请求封装成对象,以便使用不同的请求来参数化其它的对象(定义)

    *

    *

  • 注意了:一般情况下我们常见的是聪明的命令设计模式:就是说命令对象直接完成一个请求,而不是传递一个实例。
  • 以开灯来说,常见的是我们不在LightOnCommand命令对象中是不传light {new
  • LightOnCommand(light)}的,而是直接在LightOnCommand.excute方法中进行对light的操作的。
  • 但是这种常见的聪明的命令模式是没有我们传统上讲的傻瓜式的命令设计模式解耦性好的。

    */

    public
    class Test {

    public
    static
    void main(String[] args) {

    // 调用者 遥控器 把请求封装成一个对象,按下开关请命令对象去做相应的工作,遥控器并不知道工作内容是什么

    // 只要有这个命令能和正确的对象进行沟通。

    SimpleRemoteControl remote =
    new SimpleRemoteControl();

    // 接受者 厂家给的实例

    Light light =
    new Light();

    // 创建一个命令,然后将接受者给它,命令对象,命令对象控制接受者

    LightOnCommand lightOn =
    new LightOnCommand(light);

    GarageDoor garageDoor =
    new GarageDoor();

    GarageDoorOpenCommand garageOpen =
    new GarageDoorOpenCommand(garageDoor);

    // 把命令传给调用者

    remote.setCommand(lightOn);

    // 模拟按下按钮

    remote.buttonWasPressed();

    remote.setCommand(garageOpen);

    remote.buttonWasPressed();


}


}

kk

原文地址:https://www.cnblogs.com/qingruihappy/p/9739659.html

时间: 2024-08-30 16:27:11

设计模式(11)-----命令设计模式的相关文章

设计模式(12)----- 命令设计模式(升级----一个开关控制多条命令)

我们先来看张类图 RemoteControl类修改一下 public class RemoteControl {     Command[] onCommands; Command[] offCommands; public RemoteControl() { onCommands = new Command[7];          offCommands = new Command[7]; Command noCommand = new NoCommand(); for (int i = 0

iOS设计模式--备忘录设计模式与命令设计模式

何为备忘录模式? 在响应某些事件时,应用程序需要保存自身的状态,比如当用户保存文档或程序退出时.例如,游戏退出之前,可能需要保存当前会话的状态,如游戏等级.敌人数量.可用武器的种类等.游戏再次打开时,玩家可以从离开的地方接着玩.很多时候,保存程序的状态真的不需要什么特别巧妙的方法.任何简单有效的方法都可以,但是同时,保存信息应该只对原始程序有意义.原始程序应该是能够解码它所保存文档中的信息的唯一实体.这就是备忘录模式应用于游戏.文字处理等程序的软件设计中的方式,这些程序需要保存当前上下文的复杂状

设计模式之命令模式

命令模式的核心是把方法调用封装起来,调用的对象不需要关心是如何执行的. 定义:命令模式将"请求"封装成对象,以便使用不同的请求.队列或者日志来参数化其他对象.命令模式也可以支持撤销操作. 先看一个例子,设计一个家电遥控器的API,可以通过遥控器发出命令来控制不同生产商生产的家电,比如关灯.开灯. 以下是一个简单的代码示例. 1 package cn.sp.test05; 2 /** 3 * 电灯类 4 * @author 2YSP 5 * 6 */ 7 public class Lig

设计模式之命令模式20170719

行为型设计模式之命令模式: 一.含义 将请求(命令)封装成一个对象(内部有接收者对象,以及按照具体命令执行接收者操作的方法),传递给调用者,由调用者执行具体命令. 也就是把一个动作的执行分为执行对象(接收者角色).执行行为(命令角色),让两者相互独立而不相互影响,实现对动作解耦 二.代码说明 1.主要有三个角色 1)接收者角色 该角色就是干活的角色,被命令角色调用,其操作按具体命令的要求执行 2)命令角色 需要执行的所有命令都在这里声明,同时接收者所有的对象都在这里(接收者封装在这里,防止高层模

设计模式 11 —— 代理模式

设计模式目录: 设计模式 1 ——观察者模式 设计模式 2 —— 装饰者模式 设计模式 3 —— 迭代器和组合模式(迭代器) 设计模式 4 —— 迭代器和组合模式(组合) 设计模式 5 —— 工厂模式 设计模式 6 —— 单件模式 设计模式 7 —— 命令模式 设计模式 8 —— 适配器和外观模式 设计模式 9 —— 模板方法模式 设计模式 10 —— 状态模式 设计模式 11 —— 代理模式 概述 一 代理模式基本概念 二 参考 一 代理模式基本概念 代理模式为另一个对象提供一个替身或占位符以

设计模式 7 —— 命令模式

设计模式目录: 设计模式 1 ——观察者模式 设计模式 2 —— 装饰者模式 设计模式 3 —— 迭代器和组合模式(迭代器) 设计模式 4 —— 迭代器和组合模式(组合) 设计模式 5 —— 工厂模式 设计模式 6 —— 单件模式 设计模式 7 —— 命令模式 概述 第1部分 问题引入 第2部分 定义和实现 第3部分 使用宏命令 第1部分 问题引入 首先看下,下面的要求: 实现命令接口 首先,让说有的命令对象实现相同的包含一个方法的接口. 1 /** 2 * 命令接口 3 * @ClassNam

C#设计模式(15)——命令模式(Command Pattern)

原文:C#设计模式(15)--命令模式(Command Pattern) 一.前言 之前一直在忙于工作上的事情,关于设计模式系列一直没更新,最近项目中发现,对于设计模式的了解是必不可少的,当然对于设计模式的应用那更是重要,可以说是否懂得应用设计模式在项目中是衡量一个程序员的技术水平,因为对于一个功能的实现,高级工程师和初级工程师一样都会实现,但是区别在于它们实现功能的可扩展和可维护性,也就是代码的是否“优美”.可读.但是,要更好地应用,首先就必须了解各种设计模式和其应用场景,所以我还是希望继续完

设计模式:命令(Command)模式

设计模式:命令(Command)模式 一.前言 命令也是类,将命令作为一个类来保存,当要使用的时候可以直接拿来使用,比如脚本语言写出的脚本,只需要一个命令就能执行得到我们想要的需要操作很长时间才能得到的结果.这是一个非常有意思的模式,将操作的步骤保存下来,本例之中我们使用java自带的GUI来画图,然后将画图的过程(在哪个地方画了什么东西)保存下来,可以把每一次我们的操作作为一个命令,其实就是<使用什么画布,画点的坐标>,将这个命令对应的对象保存到所有命令对象的集合之中去,这样命令集合就记录下

理解设计模式(命令者)

当请求者无法或不能与接收者直接交流时,使用命令者模式. 特定环境下一类问题 以下情况适用命令者模式:程序中, 需要排队完成某些逻辑 支持撤销操作 支持宏操作 解决方案 4个角色如下: 请求者—封装抽象命令引用,发起请求,即命令执行 抽象命令—规范命令执行 具体命令—命令执行逻辑,封装接收者引用 接收者—只负责完成自身逻辑,不含任何引用 请求者作为发起者,发出请求,执行命令 最终,命令驱动接收者作出相应 优劣 优点: 请求者和接收者相互解耦 命令可扩展,符合 “开闭” 原则 请求被封装在具体命令内