Head First 设计模式 第6章 命令模式

第6章 命令模式

  在本章,我们将把封装带到一个全新的境界,把方法调用封装起来。没错,通过方法调用,我们可以把运算块包装成型。所以,调用此运算的对象不需要关心运算是如何进行的,只要知道如何使用包装成型的方法来完成它就可以。通过封装方法调用,我们还可役做一些其他很重要的事情,例如记录日志,或者重复使用封装来实现撤销操作。

  首先,让我们来看下命令模式吧。

  1丶定义:将“请求”封装成对象,以便使用不同的请求,日志或者队列来参数化其他对象,由其他对象来完成“请求”的实际调用,以达到请求的发起者和执行者之间的解偶。

  说一个命令模式的经典介绍场景吧,那就是遥控器控制电器(此处以风扇来介绍)。我们的遥控器可以打开(on)关闭(off)风扇,或者为风扇换档(1 2 3)。那么,在命令模式中是怎么实现的呢?

  首先,看一下在这个打开风扇这个过程中,都经过了哪些动作。

    1)小明拿起遥控器按下“on”按钮;

    2)遥控器接收到“on”按钮按下操作,然后将这个信号发送给风扇;

    3)风扇接受到遥控器发送的信号后,打开风扇。

  我们来分解下在这些动作中都有那些角色,进行了那些操作。

    Client-小明:发起请求(按下“on”按钮)

    Command-信号:信号会被角色传递

    Invoker-遥控器:接收信号,并把信号(Command)发送给风扇

    Receiver-风扇:按照请求,打开风扇。

  解释下命令模式的流程,就是,Client发起请求,然后把请求封装成命令对象(Command),Invoker会接收命令对象,然后执行命令,Invoker执行命令会调用Receiver的方法来完成Client的请求。对应的类图如下:  

  通过这种方式,我们就实现了请求的发起者(CLient)和执行者(Receiver)的解偶了。我请求发起之后,由调用者Invoker接收之后,即便请求发起者消亡,也不会影响该请求的执行。

  本章涉及到的新设计原则

    依赖倒置原则:尽量依赖于抽象编程,而不是具体实现

  命令模式在日志,队列的应用,后续追加......

 

如有错误,请指出,大家共同学习

如转载,请说明出处

时间: 2024-08-29 15:37:10

Head First 设计模式 第6章 命令模式的相关文章

第 12 章 命令模式【Command Pattern】

以下内容出自:<<24种设计模式介绍与6大设计原则>> 今天讲命令模式,这个模式从名字上看就很简单,命令嘛,老大发命令,小兵执行就是了,确实是这个意思,但是更深化了,用模式来描述真是是世界的命令情况.正在看这本书的你,我猜测分为两类:已经工作的和没有工作的,先说没有工作的,那你为啥要看这本书,为了以后工作呗,只要你参见工作,你肯定会待在项目组,那今天我们就以项目组为例子来讲述命令模式. 我是我们部门的项目经理,就是一个项目的头,在中国做项目,项目经理就是什么都要懂,什么都要管,做好

第14章 命令模式(Command Pattern)

原文 第14章 命令模式(Command Pattern) 命令模式(Command Pattern) 概述   在软件系统中,"行为请求者"与"行为实现者"通常呈现一种"紧耦合".但在某些场合,比如要对行为进行"记录.撤销/重做.事务"等处理,这种无法抵御变化的紧耦合是不合适的.在这种情况下,如何将"行为请求者"与"行为实现者"解耦?将一组行为抽象为对象,可以实现二者之间的松耦合[李建

大话设计模式C++实现-第23章-命令模式

一.UML图 二.概念 命令模式(Command):将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化,对请求进行排队或记录请求日志,以及支持可撤销的操作. 三.说明 角色: (1)Command类:用来声明执行操作的接口. (2)ConcreteCommand类:将一个接收者对象绑定与一个动作,调用接收者相应的操作,以实现Excute. (3)Invoker类:要求该命令执行这个请求. (4)Receiver类:知道如何实施与执行一个与请求相关的操作,任何类都可能作为一个接收者.

javascript设计模式详解之命令模式

每种设计模式的出现都是为了弥补语言在某方面的不足,解决特定环境下的问题.思想是相通的.只不过不同的设计语言有其特定的实现.对javascript这种动态语言来说,弱类型的特性,与生俱来的多态性,导致某些设计模式不自觉的我们都在使用.只不过没有对应起来罢了.本文就力求以精简的语言去介绍下设计模式这个高大上的概念.相信会在看完某个设计模式之后有原来如此的感慨. 一.基本概念与使用场景: 基本概念: 将请求封装成对象,分离命令接受者和发起者之间的耦合. 命令执行之前在执行对象中传入接受者.主要目的相互

设计模式14:Command 命令模式(行为型模式)

Command 命令模式(行为型模式) 耦合与变化 耦合是软件不能抵御变化的根本性原因.不仅实体对象与实体对象之间存在耦合关系,实体对象与行为操作之间也存在耦合关系. 动机(Motivation) 在软件构建过程中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”.但在某些场合——比如对行为进行“记录.撤销/重做(undo/redo).事务”等处理,这种无法抵御变化的紧耦合是不合适的. 在这种情况下,如何将“行为请求者”与“行为实现者”解耦?将一组行为抽象为对象,可以实现二者之间的解耦. 意

设计模式学习笔记之命令模式

命令模式 将“请求”封装成对象,以便使用不同的请求.队列或者日志来参数化其他对象.命令模式也支持可撤销的操作. 说明: 1.命令模式将发出请求的对象和执行请求的对象解耦: 2.在被解耦的两者之间是通过命令对象进行沟通的.命令对象封装了接受者和一个或一组动作: 3.调用者通过调用命令对象的execute()发出请求,这会使得接受者的动作被调用: 4.调用者可以接受命令当做参数,甚至在运行时动态地进行: 5.命令可以支持撤销,做法事实现一个undo()方法来回到exexcute()被执行前的状态:

《Head First 设计模式》学习笔记——命令模式

在软件系统,"行为请求者"与"行为实施者"通常存在一个"紧耦合".但在某些场合,比方要对行为进行"记录.撤销/重做.事务"等处理,这样的无法抵御变化的紧耦合是不合适的.在这样的情况下.怎样将"行为请求者"与"行为实现者"解耦?将一组行为抽象为对象,实现二者之间的松耦合.这就是命令模式(Command Pattern)----题记 设计模式 命令模式:将"请求"封装成对

设计模式(行为型)之命令模式(Command Pattern)

PS一句:最终还是选择CSDN来整理发表这几年的知识点,该文章平行迁移到CSDN.因为CSDN也支持MarkDown语法了,牛逼啊! [工匠若水 http://blog.csdn.net/yanbober] 阅读前一篇<设计模式(行为型)之策略模式(Strategy Pattern)>http://blog.csdn.net/yanbober/article/details/45498567 概述 在软件开发中,我们经常需要向某些对象发送请求(调用其中的某个或某些方法),但是并不知道请求的接收

Delphi 设计模式:《HeadFirst设计模式》Delphi7代码---命令模式之RemoteControlTest[转]

  1  2{<HeadFirst设计模式>之命令模式 }  3{ 本单元中的类为命令的接收者      }  4{ 编译工具 :Delphi7.0         }  5{ 联系方式 :[email protected] }  6  7unit uReceiveObject;  8  9interface 10 11type 12  TLight = class(TObject) 13  private 14    FLocation: String; 15  public 16    c