coding-hwz

《设计模式》— 行为型模式 — 解释器模式一、动机二、适用性三、结构四、参与者1、AbstractExpression2、TerminalExpression（终结符表达式）3、NonterminalExpression（非终结符表达式）4、Context5、Client五、效果1、易于改变和扩展问法2、易于实现文法3、负责的文法难以维护4、增加了新的解释表达式的方式六、实现1、创建抽象语法树2、定义解释操作3、与 Flyweight 模式共享终结符一、动机如果一种特定类型的问题发生的频率足够高，那么可

《设计模式》— 行为型模式 — 备忘录模式一、动机二、适用性三、结构四、效果1、保持封装边界2、简化了原发器3、使用备忘录可能代价很高4、定义窄接口和宽接口5、维护备忘录的签字按代价五、实现1、语言支持2、存储增量式改变一、动机有时有必要记录一个对象的内部状态。为了允许用户取消不确定的操作或从错误中恢复过来，需要实现检查点和取消机制。而要实现这些机制，你必须实现将状态信息保存在某处，这样才能将对象恢复到它们先前的状态。但是对象通常封装了其部分或所有的状态信息，使得其状态不能被其他对象访问，也就不可能在该

《设计模式》— 行为型模式 — 访问者模式一、动机二、适用性三、结构四、参与者1、Visitor2、ConcreteVisitor3、Element4、ConcreteElement5、ObjectStructure五、协作六、效果一、动机考虑一个编译器，它将源程序表示为一个抽象语法树。该编译器需要在抽象语法书上实施某些操作以进行”静态语义“分析，例如检查所有的变量是否都已经被定义了。它也需要生成代码。因此它可能要定义许多操作以进行类型检查、代码优化、流程分析，检查变量是否在使用前被赋值等。此外，还可以

《设计模式》— 结构型模式 — 享元模式一、意图一、意图有些应用程序得益于在其整个设计过程中采用对象技术，但简单化的实现代价极大。例如，大多数文档编辑器的实现都有文本格式化和编辑功能，这些功能在一定程度上是模块化的。面向对象的文档编辑器通常使用对象来表示嵌入的成分，例如表格和图形。尽管用对象来表示文档中的每个字符会极大地提高应用程序的灵活性，但是这些编辑器通常并不这样做。字符和嵌入成分可以在绘制和格式化时统一处理，从而在不影响其他功能的情况下对应用程序进行扩展，支持新的字符集。应用程序的对象结构可以模

《设计模式》— 行为型模式 — 中介者模式一、动机一、动机面向对象设计鼓励将行为分布到各个对象中。这种分布可能会导致对象间有许多连接。在最坏情况下，每一个对象都知道其他所有对象。虽然将一个系统分割成许多对象通常可以增强可复用性，但是对象间相互连接的激增又会降低其可复用性。大量的相互连接使得一个对象似乎不太可能在没有其他对象的支持下工作——系统表现为一个不可分割的整体。而且，对系统的行为进行任何较大的改动都十分困难，因为行为分布在许多对象中。这造成我们不得不定义很多子类以定制系统的行为。...

《设计模式》— 结构型模式 — 外观模式一、动机二、适用性三、结构一、动机将一个系统划分成若干个子系统有利于降低系统地复杂性。一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小。达到该目标的途径之一就是引入一个外观对象，它为子系统中较为一般的设施提供了一个单一而简单的界面。这个模式在如 Windows 操作系统中应用的十分广泛。在使用命令行作为交互工具的操作系统中，其提供的各项功能固然强大，但是这种交互方式却不适合普通用户使用。在 Windows 操作系统中，提供了一个用户界面并且对用户屏蔽了

《设计模式》— 行为型模式 — 策略模式一、动机二、适用性三、结构四、参与者1、Strategy2、ConcreteStrategy3、Context五、协作六、效果1、一个替代继承的方法2、客户必须了解不同的策略3、增加了对象的数目七、实现1、定义 Strategy 和 Context 接口2、将 Strategy 作为模板参数八、应用一、动机有许多算法可以对一个文本流进行分行。将这些算法硬编进使用它们的类中是不可取的。其原因如下：需要换行功能的客户程序如果直接包含换行算法代码的话将会变得复杂，这

《设计模式》— 行为型模式 — 迭代器模式一、动机二、适用性三、结构四、效果1、支持以不同的方式遍历一个聚合2、简化了聚合的接口3、在同一个聚合上可以有多个遍历五、实现1、谁该控制迭代2、谁定义遍历算法3、迭代器健壮性如何4、用于组合对象的迭代器六、应用一、动机一个聚合对象，如列表（list），应该提供一种方法来让别人可以访问它的元素，而又不需要暴露它的内部结构。此外，针对不同的需求，可能要以不同的方式遍历这个列表。但是即使可以预见到所需的那些便利操作，你也可能不希望列表的接口中充斥着各种不同遍历的操作

《设计模式》— 行为型模式 — 观察者模式一、动机二、适用性三、结构四、参与者1、Subject2、Observer3、ConcreteSubject4、ConcreteObserver五、协作六、效果1、目标和观察者间的抽象耦合2、支持广播通信3、意外的更新七、实现1、创建目标到其观察者之间的映射2、观察多个目标3、谁触发更新4、在发出通知前确保目标的状态自身是一致的5、避免特定于观察者的更新协议 —— 推/拉模型6、显式地指定感兴趣的改变7、封装复杂的更新语义八、应用一、动机将一个系统分割成一系列相

《设计模式》— 行为型模式 — 命令模式一、动机二、适用性三、结构四、参与者1、Command2、ConcreteCommand3、Client4、Invoker5、Receiver五、协作六、效果七、实现1、一个命令对象应达到何种智能程度2、支持撤销和重做3、使用C++模板类八、应用一、动机有时必须向某对象提交请求，但并不知道关于被请求的操作或请求的接受者的任何信息。例如，用户界面包括按钮和菜单这样的对象，它们执行请求响应用户输入。但工具箱不能显式地在按钮或菜单中实现该请求，因为只有使用工具箱的应用知

《设计模式》— 行为型模式 — 模板方法模式一、动机一、动机考虑一个提供 Application 和 Document 类的应用框架。Application 类负责打开一个已有的以外部形式存储的文档，如一个文件。一旦一个文档中的信息从该文件中读出后，它就由一个 Document 对象表示。用框架构建的应用可以通过继承 Application 和 Document 来满足特定的需求。例如，一个绘图应用定义 DrawApplication 和 DrawDocument 子类等，如下所示。这里的 cre

《设计模式》— 行为型模式 — 状态模式一、动机二、适用性三、结构四、参与者1、Context2、State3、Concrete State五、协作六、效果1、将与特定状态相关的行为局部化，并且将不同状态的行为分割开来2、使得状态转换显式化3、State 对象可被共享七、实现1、谁定义转换2、基于表的另一种方法3、创建和销毁对象八、应用1、State（1）抽象类（2）初始状态（3）读取字符状态（4）读取转义字符状态（5）结束读取类2、Context3、测试4、对比一、动机考虑一个表示网络连接的类 TCP

《设计模式》— 行为型模式 — 责任链模式一、动机二、适用性三、结构四、参与者1、Handler2、ConcreteHandler3、Client五、效果1、降低耦合度2、增加了给对象指派职责的灵活性3、不保证被接受六、实现1、实现后继者链2、连接后继者3、表示请求七、应用一、动机考虑一个图形用户界面的上下文有关的帮助机制。用户在界面的任一部分点击就可以得到帮助信息，所提供的帮助依赖于点击的是界面的哪一部分及其上下文。例如，对话框中按钮的帮助信息就可能和主窗口中类似的按钮不同。如果对那一部分界面没有特定

《设计模式》— 结构型模式 — 代理模式一、动机二、适用性三、结构四、参与者1、Proxy2、Subject3、RealSubject五、实现1、C++中的存取运算符2、代理并不总是需要知道实体的类型六、实现1、抽象类及被代理类2、代理工厂3、handler4、测试七、相似设计模式一、动机对一个对象进行访问控制的一个原因是只有我们确实需要这个对象时才对它进行创建和初始化。我们考虑一个可以在文档中嵌入图形对象的文档编辑器。有些图形对象的创建开销很大。但是打开文档必须很迅速，因此我们在打开文档时应避免一次性

《设计模式》— 结构型模式 — 装饰模式（包装器）一、动机二、适用性三、结构四、参与者1、Component2、ConcreteComponent3、Decorator4、ConcreteDecorator五、协作六、效果1、比静态继承更灵活2、避免在层次结构高层的类有太多的特征3、Decorator 与它的 Component 不一样4、有许多小对象七、实现1、接口的一致性2、省略抽象的 Decorator 类3、保持 Component 的简单性4、改变对象外壳与改变对象内核八、应用举例一、动机有时

《设计模式》— 结构型模式 — 组合模式一、问题来源二、适用性三、结构四、参与者1、Component(Graphic)一、问题来源在绘图编辑器和图形捕捉系统这样的图形应用程序中，我们可以通过组合已有的组件形成新的组件加入到工具箱中。一个简单的实现方式是为所有基本元素定义一些类，另外定义一些类作为这些图元的容器类。这种方法存在一个问题：使用这些类的代码必须区别对待图元对象与容器对象，而实际上对于用户来说，它们是一致的。对这些类区别使用，将造成设计和实现上的困难。我们可以通过组合模式递归组合，使得用户不

《设计模式》— 结构型模式 — 桥接模式一、问题来源二、类图三、适用范围1、你不希望在抽象和它的实现部分之间有一个固定的绑定关系2、类的抽象以及它的实现都应该可以通过生成子类的方式加以扩充3、对一个抽象的实现部分的修改对客户不产生影响，即客户的代码不必重新编译4、（C++）可以完全隐藏抽象的实现部分5、当有同一个抽象的许多子类要生成，而他们的功能又是相互耦合的6、你想在多个对象间共享实现，但同时要求客户不知道这点。四、参与者1、Abstraction2、RefinedAbstraction3、Impleme

《设计模式》— 结构型模式 — 适配器模式一、问题来源二、类图三、适用范围1、你想使用一个已经存在的类，而它的接口不符合你的需求2、你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作3、（仅适用于对象适配器）你想使用一些已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口一、问题来源考虑一个绘图编辑器。图形对象的接口应该有抽象的定义，不妨命名为Shape。这样我们可以为绘制直线的类命名为LineShape，多

《设计模式》—创建型模式—原型模式一、问题来源一、问题来源考虑一个应用于绘制五线谱的工具。我们需要一个抽象的Graphic类，其子类包括不同长度的音符类。同时我们需要提供一个工具类GraphicTool用于创建图形实例。然而，与前面我们讨论过的工厂方法模式一样。对于框架来说，它并不知道自己要实例化的对象是属于Graphic的哪个子类的。那么我们是否可以考虑使用工厂方法模式来解决此问题呢？可以，但是这样的结果就是为了创建一个具体的Graphic类，我们需要一个具体的Creator类，非常冗余。这里就可以

《设计模式》—创建型模式—生成器模式一、问题来源二、类图一、问题来源考虑一个应用框架，它可以像用户显示多种文档。不同的实现者继承或实现相应的接口以提供不同文档的解析和显示。对于框架来说，某些操作可以是固定的。以新建文档的过程举例，我们将创建的文档对象添加到文档集合的列表中是固定的。但是，创建文档对象本身这个操作是由具体应用所定义的。因此框架需要将创建文档对象声明为抽象函数。其实现被延迟到子类。二、类图从类图我们可以看出，实际上是抽象类的一部分行为被延迟到子类实现。结合我们上面讨论的应用场景，我们就

《设计模式》—创建型模式—生成器模式一、问题来源二、类图三、适用范围1、当创建复杂对象的算法应该独立与该对象的组成部分以及它们的装配方式时。2、当构造过程必须允许被构造的对象有不同的表示。四、参与者1、Builder五、时序六、优点七、实现八、代码实例九、相似设计模式比较一、问题来源一个 RTF 文档交换格式的阅读器支持将 RTF 转换为多种文本格式。这个过程可以简化为两部分：读取并解析 RTF 文档，对解析到的关键字和标识符进行转化和拼接输出目标格式。显然，这两部分并不对等。第一步对于所有的目标格式都

设计模式—创建型模式—抽象工厂模式一、问题来源二、类图一、问题来源如何实现程序的跨平台性？即不需重新编写代码，只需重新编译代码（如Qt）或使用不同的运行环境（JVM）即可使可执行文件在不同平台运行？考虑一个gui工具箱，如何在用户无感知的情况下提供不同系统的支持？二、类图...