设计模式-行为模式Chp7
设计模式（1、创造型2、结构型、3行为型）
设计模式（1、创造型2、结构型、3⾏为型）
设计模式六⼤原则：单⼀职责、⾥⽒替换、依赖倒置、最⼩接⼝、迪⽶特、开闭
这些只能叫原则,叫建议,没有实际的招数
23种设计模式，就是具体的招数，他们可以分成三⼤类。
1、创造型2、结构型、3⾏为型。
创造型设计模式关注对象的创建。
就是咱们的new().单例模式、原型模式、⼯⼚⽅法、抽象⼯⼚、建造者模式
结构型设计模式关注类与类之间的关系。
继承或者组合。
说⽩了就是包⼀层。
适配器模式、代理模式、装饰器模式、外观模式、组合模式、桥接模式、享元模式
⾏为型设计模式关注对象和⾏为的分离。
流程⽤的多些，说⽩了就是把逻辑丢出去，具体逻辑上端⾃⼰实现，下端只做流程。
模板⽅法设计模式、观察者模式、责任链模式
23种设计模式是前辈们总结出来的。
是为了解决具体的⼀类问题总结出来的，我遇到好多⼩伙伴觉得设计模式很⽜逼。
其实没那么伟⼤。
某种设计模式解决⼀类问题也会带来另⼀种问题。
所以合理应⽤才是最好的。
所以，有些设计模式不是必须应⽤进去。
不必强求。
我也是后来者，对前辈们总结的⼀些理解，学习和应⽤。
希望也能帮到看到这⾥的求学者。
下⾯⼏章。
都是对这23种设计模式的解读，不过我是总结成三⼤类。
尽量⽤最普通的话去阐述。
清华结构力学求解器用法
连续显示：观览器的缺省状态，此时观览器随时根 据编辑器中的活动文档的命令行绘出最新的图形。
暂停显示：此时观览器被“冻结”，不再对编辑器 中活动文档的命令改变发生反应。 停止单步显示：用于中断单步显示。
14
⒌ 定义问题有关参数的步骤 ① 问题定义：确定新问题开始，输入新问题标题，通 过对话框选择方式也可以结束当前问题；
13
加大幅值：增加内力图或位移图等的显示幅度，而 结构图大小和外观不变。
减小幅值：减小内力图或位移图等的显示幅度，而 结构图大小和外观不变。 单步显示：观览器一次只读取编辑器中活动文档的 一条命令，并相应地加以显示。 单步显示钮按下后，工具 栏的最右方将出现一个“停止单步显示”按钮，可用于中断 单步显示。
了一倍。
⒊ 修改功能 中文关键词：为了方便对输入命令的修改，添加了中文 关键词选项(“查看”菜单下)，并将其设为默认方式，即用 对话框输入的命令默认为中文关键词。
7
“修改”工具钮：将光标置于要查看或修改的命令行 ，单击“修改”工具钮，即可返回到输入该命令的对话框， 重现各个参数值。若不修改，单击“关闭”；若有修改，单 击“应用”即可。
⒉ 求解功能
组合结构：智能求解模式增添了平面“静定组合结构” 的求解，按三种模式(所有杆件内力、作弯矩图需要的内力 、指定杆件的内力)以文本或图文形式给出解题步骤。 四精度求解：可选用四精度实型数(约28位)求解，结果 更精确、可更好地模拟无穷大刚度。
6
几何构造检验：v1.0版中求解时先进行几何构造检验， 此版本中可设为否，以提高求解速度。 求解速度提高：求解速度提高3-4倍，一个10跨20层的 刚架的基频和相应的振型计算(学生版不行)，达到0.1%的精 度，在PII333上只用0.5秒。 求解规模加倍：求解问题对单元数的限制比v1.0版放松
计算机组成原理白中英主编课件chp7
此地址格式表示有4台磁盘（2位），每台有16个记录面/盘面（4位）， 每面有256个磁道（8位），每道有16个扇区（4位）。 (5)如果某文件长度超过一个磁道的容量，应将它记录在同一个柱面上，因为 不需要重新找道，数据读/写速度快。
21
7.3磁盘存储设备的技术发展 磁盘存储设备的技术发展
20
解：(1)有效存储区域=16.5-11=5.5(cm) 因为道密度=40道/cm，所以40×55=220道，即220个圆柱面。 (2)内层磁道周长为2πR=2×3.14×11=69.08(cm) 每道信息量=400位/cm×69.08cm=27632位=3454B 每面信息量=3454B×220=759880B 盘组总容量=759880B×10=7598800B (3)磁盘数据传输率Dr=rN N为每条磁道容量，N=3454B r为磁盘转速，r=6000转/60秒=100转/秒 Dr=rN=100×3454B=345400B/s (4)采用定长数据块格式，直接寻址的最小单位是一个记录块(一个扇区)，每 个记录块记录固定字节数目的信息，在定长记录的数据块中，活动头磁 盘组的编址方式可用如下格式：
12
13
7.2磁盘存储设备 磁盘存储设备
四、磁盘上信息的分布 盘片的上下两面都能记录信息，通常把磁 盘片表面称为记录面。记录面上一系列同心圆 称为磁道。每个盘片表面通常有几百到几千个 磁道，每个磁道又分为若干个扇区，如下一页 图所示。从图中看出，外面扇区比里面扇区面 积要大。磁盘上的这种磁道和扇区的排列称为 格式。
存储容量：一个磁盘存储器所能存储的字节总数， 称为磁盘存储器的存储容量。
17
7.2磁盘存储设备 磁盘存储设备
存取时间：存取时间是指从发出读写命令后，磁头从 某一起始位置移动至新的记录位置，到开始从盘片表 面读出或写入信息加上传送数据所需要的时间。取决 于以下三个因素决定：
设计模式分类（创建型模式、结构型模式、行为型模式）
设计模式分类（创建型模式、结构型模式、⾏为型模式）1．创建型模式前⾯讲过，社会化的分⼯越来越细，⾃然在软件设计⽅⾯也是如此，因此对象的创建和对象的使⽤分开也就成为了必然趋势。
因为对象的创建会消耗掉系统的很多资源，所以单独对对象的创建进⾏研究，从⽽能够⾼效地创建对象就是创建型模式要探讨的问题。
这⾥有6个具体的创建型模式可供研究，它们分别是：简单⼯⼚模式（Simple Factory）⼯⼚⽅法模式（Factory Method）抽象⼯⼚模式（Abstract Factory）创建者模式（Builder）原型模式（Prototype）单例模式（Singleton）说明：严格来说，简单⼯⼚模式不是GoF总结出来的23种设计模式之⼀。
2．结构型模式在解决了对象的创建问题之后，对象的组成以及对象之间的依赖关系就成了开发⼈员关注的焦点，因为如何设计对象的结构、继承和依赖关系会影响到后续程序的维护性、代码的健壮性、耦合性等。
对象结构的设计很容易体现出设计⼈员⽔平的⾼低，这⾥有7个具体的结构型模式可供研究，它们分别是：外观模式/门⾯模式（Facade门⾯模式）适配器模式（Adapter）代理模式（Proxy）装饰模式（Decorator）桥梁模式/桥接模式（Bridge）组合模式（Composite）享元模式（Flyweight）3．⾏为型模式在对象的结构和对象的创建问题都解决了之后，就剩下对象的⾏为问题了，如果对象的⾏为设计的好，那么对象的⾏为就会更清晰，它们之间的协作效率就会提⾼，这⾥有11个具体的⾏为型模式可供研究，它们分别是：模板⽅法模式（Template Method）观察者模式（Observer）状态模式（State）策略模式（Strategy）职责链模式（Chain of Responsibility）命令模式（Command）访问者模式（Visitor）调停者模式（Mediator）备忘录模式（Memento）迭代器模式（Iterator）解释器模式（Interpreter）。
行为型设计模式介绍
行为型设计模式介绍行为型设计模式是指用于解决对象之间交互及职责分配的设计模式，它们主要描述了不同对象之间的通信方式，以及如何控制对象之间的交互流程。
这些模式通过将行为分离到不同的对象中，来实现更好的封装性和可复用性。
在本篇论文中，我们将对行为型设计模式做一个简要的介绍，包括模式的定义、分类以及如何在实际开发中应用它们。
一、定义行为型设计模式是指一系列用于对象之间交互和职责分配的设计模式。
这些模式主要解决对象间的通信方式以及如何控制对象之间的交互流程。
与创建型设计模式和结构型设计模式不同，行为型设计模式更关注对象之间的功能分配，而不是组成对象的方式。
行为型设计模式主要包括以下几种：1、责任链模式：将请求的发送者和接收者解耦，构造成一条链，依次发送请求，直到有一个接收者处理为止。
2、命令模式：将请求封装成对象，使得请求的发送者与请求的接收者之间解耦，并且可以动态地添加或删除请求。
3、迭代器模式：提供一种方法来顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。
4、中介者模式：定义一个中介对象来封装一系列对象之间的交互，使得各对象之间不需要直接相互作用，从而降低耦合度。
5、备忘录模式：提供一种方式来捕获对象的内部状态，并可以在需要的时候恢复对象到之前的状态。
6、观察者模式：对象之间的一种一对多的依赖关系，当一个对象状态改变时，所有依赖它的对象都会得到通知并且自动更新。
7、状态模式：允许一个对象在其内部状态改变时改变其行为，从而使对象看起来似乎修改了其所属的类。
8、策略模式：定义了一系列算法，并将每个算法都封装起来，使得它们可以互相替换。
9、模板方法模式：定义了一个算法框架，由具体子类实现其中的某些步骤，可以提供一个保护性的具体方法，以约束它的子类必须遵循的规则。
10、访问者模式：在不改变对象的前提下，定义作用于对象某些元素的新操作。
二、分类行为型设计模式可以分为两类：类行为型模式和对象行为型模式。
行为型模式
行为型模式1.简介描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。
行为型模式包括：模板方法模式、策略模式、命令模式、责任链模式、状态模式、观察者模式、中介者模式、迭代器模式、访问者模式、备忘录模式、解释器模式。
2.行为型模式分类(1)模板方法模式说明：将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
优点它封装了不变部分，扩展可变部分。
它把认为是不变部分的算法封装到父类中实现，而把可变部分算法由子类继承实现，便于子类继续扩展。
它在父类中提取了公共的部分代码，便于代码复用。
部分方法是由子类实现的，因此子类可以通过扩展方式增加相应的功能，符合开闭原则。
缺点对每个不同的实现都需要定义一个子类，这会导致类的个数增加，系统更加庞大，设计也更加抽象。
父类中的抽象方法由子类实现，子类执行的结果会影响父类的结果，这导致一种反向的控制结构，它提高了代码阅读的难度。
抽象类源码(2)策略模式说明：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户。
抽象策略类源码环境类源码（3）命令模式说明：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
方便将命令对象进行储存、传递、调用、增加与管理。
优点降低系统的耦合度。
命令模式能将调用操作的对象与实现该操作的对象解耦。
（4）增加或删除命令非常方便。
采用命令模式增加与删除命令不会影响其他类，它满足“开闭原则”，对扩展比较灵活。
可以实现宏命令。
命令模式可以与组合模式结合，将多个命令装配成一个组合命令，即宏命令。
方便实现Undo和Redo操作。
命令模式可以与后面介绍的备忘录模式结合，实现命令的撤销与恢复。
缺点：可能产生大量具体命令类。
因为计对每一个具体操作都需要设计一个具体命令类，这将增加系统的复杂性。
设计模式七大原则
设计模式七⼤原则1. 设计模式的⽬的编写软件过程中，程序员⾯临着来⾃耦合性，内聚性以及可维护性，可扩展性，重⽤性，灵活性等多⽅⾯的挑战，设计模式是为了让程序(软件)，具有更好的 1) 代码重⽤性 (即:相同功能的代码，不⽤多次编写) 2) 可读性 (即:编程规范性, 便于其他程序员的阅读和理解) 3) 可扩展性 (即:当需要增加新的功能时，⾮常的⽅便，称为可维护) 4) 可靠性 (即:当我们增加新的功能后，对原来的功能没有影响) 5) 使程序呈现⾼内聚，低耦合的特性分享⾦句: 设计模式包含了⾯向对象的精髓，“懂了设计模式，你就懂了⾯向对象分析和设计(OOA/D)的精要” Scott Mayers 在其巨著《Effective C++》就曾经说过:C++⽼⼿和 C++新⼿的区别就是前者⼿背上有很多伤疤2. 设计模式七⼤原则设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础（即：设计模式为什么这样设计的依据）设计模式常⽤的七⼤原则有:1. 单⼀职责原则2. 接⼝隔离原则3. 依赖倒转（倒置）原则4. ⾥⽒替换原则5. 开闭原则6. 迪⽶特法则7. 合成复⽤原则3. 单⼀职责原则（SingleResponsibility）基本介绍 对类来说的，即⼀个类应该只负责⼀项职责。
如类 A 负责两个不同职责：职责 1，职责 2。
当职责 1 需求变更⽽改变 A 时，可能造成职责 2 执⾏错误，所以需要将类 A 的粒度分解为 A1，A2应⽤实例 以交通⼯具案例讲解package com.atguigu.principle.singleresponsibility;public class SingleResponsibility1 {public static void main(String[] args) {Vehicle vehicle = new Vehicle();vehicle.run("摩托车");vehicle.run("汽车");vehicle.run("飞机");}}/*** 交通⼯具类* ⽅式⼀* 1. 在⽅式⼀的 run ⽅法中，违反了单⼀职责原则* 2. 解决的⽅案⾮常的简单，根据交通⼯具运⾏⽅法不同，分解成不同类即可*/class Vehicle{public void run(String vehicle){System.out.println(vehicle + "在公路上运⾏...");}}⽅案⼀package com.atguigu.principle.singleresponsibility;public class SingleResponsibility2 {public static void main(String[] args) {RoadVehicle roadVehicle = new RoadVehicle();roadVehicle.run("摩托车");roadVehicle.run("汽车");AirVehicle airVehicle = new AirVehicle();airVehicle.run("飞机");}}/*** ⽅案⼆的分析* 1. 遵守单⼀职责原则* 2. 这样做的改动很⼤，即将类分解，同时修改客户端* 3. 改进：直接修改 Vehicle 类，改动的代码会⽐较少 => ⽅案三*/class RoadVehicle{public void run(String vehicle){System.out.println(vehicle + "在公路运⾏");}}class AirVehicle{public void run(String vehicle){System.out.println(vehicle + "在天空运⾏");}}class WaterVehicle{public void run(String vehicle){System.out.println(vehicle + "在⽔中运⾏");}}⽅案⼆package com.atguigu.principle.singleresponsibility;public class SingleResponsibility3 {public static void main(String[] args) {Vehicle2 vehicle2 = new Vehicle2();vehicle2.run("摩托车");vehicle2.runAir("飞机");vehicle2.runWater("轮船");}}/*** ⽅式三的分析* 1. 这种修改⽅法没有对原来的类做⼤的修改，只是增加⽅法* 2. 这⾥虽然没有在类这个级别上遵守单⼀职责原则，但是在⽅法级别上，仍然是遵守单⼀职责 */class Vehicle2{public void run(String vehicle){System.out.println(vehicle + "在公路运⾏...");}public void runAir(String vehicle){System.out.println(vehicle + "在天空运⾏...");}public void runWater(String vehicle){System.out.println(vehicle + "在⽔中运⾏...");}}⽅案三单⼀职责原则注意事项和细节1. 降低类的复杂度，⼀个类只负责⼀项职责2. 提⾼类的可读性，可维护性3. 降低变更引起的风险4. 通常情况下，我们应当遵守单⼀职责原则，只有逻辑⾜够简单，才可以在代码级违反单⼀职责原则; 只有类中⽅法数量⾜够少，可以在⽅法级别保持单⼀职责原则4. 接⼝隔离原则(Interface Segregation Principle)基本介绍 1. 客户端不应该依赖它不需要的接⼝，即⼀个类对另⼀个类的依赖应该建⽴在最⼩的接⼝上 2. 看图： 3. 类A通过接⼝ Interface1 依赖类B，类C通过接⼝ Interface1 依赖类D，如果接⼝ Interface1 对于类A和类C来说不是最⼩接⼝，那么类B 和类 D 必须去实现他们不需要的⽅法。
菜鸟学设计模式(28天)
菜鸟学设计模式（28天）原则：开放——封闭原则（OCP）：——对扩展开放，对修改关闭。
里氏代换原则(LSP)：——子类型必须能够替代它们的基类型依赖倒置原则(DIP) ：——抽象不应当依赖于细节；细节应当依赖于抽象；要针对接口编程，不针对实现编程。
接口隔离原则(ISP)：——使用多个专门的接口比使用单一的总接口总要好迪米特法则(LoD)/最少知识原则(LKP) ：——一个对象应当对其它对象有尽可能少的了解模式：Simply Factory Pattern：当我们在买早餐的时候，早餐店里都卖得写什么呢？这点你有注意吗？众多食品摆在那里，你只对营业员说你要何种食品，他便会知道给你拿什么样的食品给你，这说明什么呢？如果用面向对象的思想来理解的话，营业员在这里就充当了一个工厂的角色，他负责根据你的请求返回你需要的食品对象。
而这一点正是简单工厂模式的意图地二天：Strategy Pattern策略模式是一种定义一系列算法的方法，概念上：都是为了完成同一个任务，只是实现不同。
它可以以相同的方式调用各种算法，降低算法类之间的耦合，利于扩展。
第三天：Decorator Patternusing System;using System.Collections.Generic;using System.Linq;using System.Text;namespace DecoretorPattern{public class Water{public virtual void Add() { }}public class Decoretor : Water{public Water ww;public void SetDecoretor(Water ww) {this.ww = ww;}public override void Add(){if (ww != null){ww.Add();}}}public class AddIce:Decoretor{public override void Add(){base.Add();Console.WriteLine("AddIce");}}public class AddCoffee : Decoretor{public override void Add(){base.Add();Console.WriteLine("AddCoffee");}}class Program{static void Main(string[] args){AddCoffee coffee = new AddCoffee();AddIce ice = new AddIce();coffee.SetDecoretor(new Water());ice.SetDecoretor(coffee);ice.Add();Console.ReadLine();}}}装饰器模式：动态的给某对象添加一些额外的职责，把类本身具备的装饰功能从其本身划分出去，当需要时，随时随地的配上需要的功能。
CCHP系统介绍
楼宇型项目案例： ——北京铁路南站能源中心 面积约14万m2
天
然
太阳能电池板
气
空气
余热烟气
燃气发电机组 补燃天然气
国内首个污水源热泵、太阳 能、燃气三联供集成项目
发电3000kW,并网运行
电力负荷 余热回收装置
空气
定义：1）分布在用户周边；2）真正实现
了对能源的梯级利用；3）系统全年能源
天
利用率不低于70%。
然
气
燃气发电机组
(30%) (50%)
余热烟气
补燃天然气
余热回收装置
电力负荷
热水负荷 采暖负荷 制冷负荷
能源设施：从大到小、从远到近
大型电厂发电效率40~50% 50%的能源以废热形式排放 冷热传输受距离限制
4
8
12
16
20
24
小时(hr)
热负荷(kW)
对负荷需要更精准的分析
负荷分析软件：Energy Plus 1.或2等，及国内开发的软件
天然气冷热电三联供设备构成
发电设备
燃气微燃机
35-1000KW
燃气内燃机
200-10000KW
燃气轮机
3MW-300MW
开普斯通 英格索兰
褒曼 康明斯 彦巴赫
卡特彼勒 GE 美国索拉 川崎重工
.7JC 吨！ 5 8 Z. l
咆饥~~ "e ff-fill ＆揭宦
但二 k唱， . . .
火电 24 2~ I l!tl97. 7
亿 kW· h I
玛巴 为
3006. 3
£ kW· h
设计思维个阶段分析案例
PART 2
定义
定义
定义阶段是对同理心阶段收集的数据进行分析和总结，确定问题的核心和目标。在这 个阶段，我们需要明确问题的重要性和优先级，并制定相应的设计目标和约束条件
定义
1 以快餐店为例，经过同理心阶段的分析，我 们可以将问题归纳为"如何缩短顾客排队等 待时间"和"如何提高点餐的准确率"。在设 计目标方面，我们可以设定为"提高顾客满 意度"和"降低餐厅运营成本"
在测试过程中，我们需要收集顾客的反 馈和建议，并对原型进行改进和完善
通过对原型的不断优化和迭代，我们可 以得出一个稳定、高效的线上点餐系统
PART 5
测试
测试
1 测试阶段是对原型进行实际使用和评估 的阶段
2 在这个阶段，我们需要将原型投入实际 使用，并收集顾客的反馈和建议
3 同时，我们还需要对产品的性能、稳定 性、易用性等方面进行评估和测试
设计思维5个阶段分析案 例
-
目 录 C O N T E N T S
01
02
03
04
同理心
定义
创意
原型
05
测试
06
用户为中心
07
迭代和优 化
设计思维5个阶段分析案例
设计思维是一个解决问题的方法论，它包括五个阶段：同理心、定义、创意、原型和测试 。下面以一个案例来展示这五个阶段
PART 1
同理思维是一种创新性的解决问题方法论，它包括同理心、定义、创意、原型 、测试等五个阶段，并以用户为中心、迭代和优化为关键方面。通过运用设计思维，设计 师可以更好地理解用户需求和市场变化，创造出更为实用、便捷、个性化的产品或服务， 提高用户的满意度和忠诚度
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
支持取消操作
4. 适用性
支持修改日志
在系统崩溃后按照日志重新执行Execute操 作
用构建在原语操作上的高层操作构造一 个系统
Transaction事务，封装了对数据的一组变动
5. 结构
6. 参与者
Command
声明执行操作的接口
ConcreteCommand (PasteCommand, OpenCommand)
仅需保持一个指向后继者的引用 不需保持所有候选接受者的引用
7. 效果
2) 增强了给对象指派职责(Responsibility) 的灵活性（优点）
在运行时刻对职责链进行动态增加和修改
3) 不保证被接受（缺点）
一个请求，不能保证它一定会被处理
8.实现
1) 实现后继者链 a) 定义新的链接 通常在Handler类中定义
9.代码示例
Button类
9.代码示例
Dialog类
Dialog类的后继是任 意的请求帮助处理 对象，而不是一个 窗口组件
9.代码示例
Application类，链的末端
9.代码示例
创建并连接这些对象，这些对象可以动态 地连接
Client
从按钮开始触发请求
11.相关模式
职责链常与Composite模式一起使用
3. 动机
应用为每个菜单项配置一个Command子类的实例。当 用户选择一个菜单，MenuItem调用它的Command实 例的Execute方法，执行相应操作。MenuItem并不知 道它使用的Command是哪个子类
3. 动机
PasteCommand对象
向文档粘贴正文
3. 动机
OpenCommand: •提示输入文件名 •创建相应的文件文档 •将文档载入到应用中 •打开文档
方式2: 使用一个处理函数
8.实现
用Request类描述请求，新类型的请求用子类定义
用独立的请求对象来封装请求参数
8.实现
子类扩展：只处理其感兴趣的请求， 其它交给父类
9.代码示例
检索是否存在相关的帮助主题
HelpHandler类
9.代码示例
后继为_parent
窗口组件类 Widget Widget是HelpHandler的子类
如果命令的状态从不改变，则仅将对该命令的 引用放入历史序列
9.实现
3) 避免取消操作过程中的错误积累 在Command中存入更多的信息以保证这些对 象被精确复原成其初始状态 可使用Memento模式
4)使用C++模板 对(1)不能撤销(2)不需要参数的命令，可使用 C++模板来实现 避免为每一种动作和接收者都创建一个 Command子类
2) 支持取消(undo)和重做(redo) Command提供reverse操作(Unexecute或者 Undo操作) 此时，ConcreteCommand类需要额外的状态 信息
接收者对象，其上执行的操作 接收者上执行操作的参数 如果该操作改变了接收者对象的值，则需要存储这 些值
例，用户界面工具箱，提供菜单、按钮，能够接受 用户的请求（即按下按钮），但是只有使用工具箱 的用户才知道按钮让哪个对象做什么事情。
命令模式将请求本身变成一个对象，可向未指 定的应用对象提出请求
抽象Command类，具有Execute()接口 具体的Command子类将接收者作为一个实例变量， 实现Execute操作
4. 结构
对象结构
5. 参与者
Handler (HelpHandler)
ConcreteHandler ( PrintButton, PrintDialog)
定义一个处理请求的接口 (可选)实现后继链
处理它所负责的请求 可访问它的后继者 如果可处理请求，则处理；否则将请求转发给它的 后继者
5.1 Chain of Responsibility 职责链
1. 意图
使多个对象都有机会处理请求，从而避 免请求的发送者和接收者之间的耦合关 系
将这些对象连成一条链，并沿着这条链 传递该请求，直到有一个对象处理它为 止。
2. 动机
图形用户界面中的Context有关的帮助机制
用户在界面上点击可得帮助信息 得到特定的帮助信息（如某按钮的帮助信息）或一 般性的帮助信息 根据普遍性（generality）组织帮助信息
一个组件的父组件可作为它的后继
5.2 Command 命令
Command模式
1. 意图 将一个请求封装为一个对象，从而可用不同的 请求对客户进行参数化 对请求排队或记录请求日志，以及支持可撤销 的操作 2. 别名 动作(Action) 事务(Transaction)
3. 动机
向某对象提交请求，但并不知道被请求操作或 请求接受者的任何信息
2. 动机
一个抽象类和四个子类
RegularExpression的每一个子类定义Interpret操作，构成这些正则表达式的一个 解释器。 将该表达式的上下文作为一个参数。上下文包含输入字符串和已匹配的信息
2. 动机
形成由这些类 构成的实例的抽象语法树 raining & (dogs | cats) *
向链上的具体处理者(ConcreteHandler)对象提交请 求
Client
6. 协作
当客户提交一个请求时，请求沿链传递 直至有一个ConcreteHandler对象负责处 理它
7. 效果
1） 降低耦合度（优点）
接收者和发送者都没有对象的明确信息，且 链中的对象不需知道链的结构 职责链可简化对象的相互连接
仅需知道如何提交它（按钮、菜单） 不需知道该请求将会被如何执行
4. 适用性
抽象出待执行的动作以参数化某对象 在不同的时刻指定、排列和执行请求
Command对象可以有与初始请求无关的生 命周期 存储操作实施前的状态 Command类添加Unexecute接口 通过前后遍历状态列表实施“取消”和“重 做”
b) 使用已有的链接 e.g. 复用Composite模式中的链等（子组 件引用父组件）
8.实现
2) 连接后继者
Handler不仅定义请求的接口， 也维护后继链接
初始化successor为s
8.实现
3) 表示请求 方式1：硬编码(hard-coded)的操作调用
方便、安全； 只能处理Handler类中定义的固定的一组请求 处理函数以一个请求码为参数 优点：更为灵活 缺点：无法用类型安全的方法传递请求参数，必须 手工做类型转换
10.代码示例
创建一个调用MyClass类实例上的Action的 Command对象
C++模板类仅适用于简单命令，无需维护接收者和 登记参数
10.代码示例
MacroCommand : 子命令序列
10.代码示例
管理子命令
12. 相关模式
Composite模式：用于实现宏命令
Memento模式
2. 动机
“Print”按钮的帮 助信息 最终显示整个程序 应用的帮助信息
每个链条上对象必须一致的处理请求和访问链上后继者 的接口
2. 动机
3. 适用性
有多个对象可以处理一个请求
哪个对象处理该请求，由运行时刻自动确定
在不明确接收者的情况下，向多个对象 中的一个提交一个请求
可处理一个请求的对象集合应被动态指 定
OpenCommand
3. 动机
一个MenuItem需要执行一系列命令 定义一个MacroCommand类让一个 MenuItem执行任意数目的命令
宏命令：命ቤተ መጻሕፍቲ ባይዱ序列
3. 动机
菜单和按钮代表同一功能
共享Command对象
将多个命令组合形成命令脚本(command scripting)
核心：提交一个请求的对象
接收者需要提供操作，以便恢复到先前状态
9.实现
2) 支持取消(undo)和重做(redo) 已执行命令的历史序列(history list)
向后遍历：undo 向前遍历：redo
如果命令的状态在各次调用之间会发生变化， 则必须将完整拷贝放入历史序列以区分不同调 用
e.g. DeleteCommand命令对象，删除选定对象
从最特殊到最普通 使用Chain of Responsibility模式，使得请求者和响应者解 耦(decouple) 给多个对象处理一个请求的机会
提交请求的对象不知道谁是最终提供响应的对象
2. 动机
隐式的接收者(implicit receiver)
链条上每一个接收者要么亲自处理，要么转发给下一个对象 提交请求的对象并不明确知道哪个对象将会处理它
可在操纵前存储状态
ConcreteCommand对象调用它的Receiver的一 些操作执行该请求
7. 协作
8. 效果
将调用操作的对象(Invoker)与知道如何 实现该操作的对象(Receiver)解耦 Command可以像其他对象一样操作以及 扩展 多个命令装配成一个复合命令
Composite模式
10.代码示例
抽象Command类