设计模式问答2

介绍

这是设计模式问答1的连载。在这个系列，我们将覆盖到解释器、迭代器、调停者、备忘录和观察者模式。

如果你还没有阅读过我之前的系列，你可以随时从下面开始

设计模式问答1：工厂模式，抽象工厂模式，构造者模式，原型模式，单例模式，命令模式
设计模式问答3：状态模式，策略模式，访问者模式，适配器模式，享元模式
设计模式问答4：桥接模式，组合模式，装饰者模式，外观模式，职责链模式（COR），代理模式，模板模式
UML问答1：UML部分1
UML问答2：UML部分2

什么是解释器模式？

解释器模式允许我们将语法解释为代码解决方案。好了，这意味着什么？语法会被映射到类，并形成解决方案。举个例子，7 – 2能够被映射到“clsMinus”类。一句话，解释器模式为我们提供了一种解决方案，这个方案指导如何编写一个解析语法并执行代码的解释器。下面是一个解释器的简单例子，它能够按照我们提供的日期格式语法，将日期解释为对应的代码，并输入正确的结果。

日期语法

让我们开始做图“日期语法”中所示的日期格式的解释器。在开始之前，我们要先理解一下解释器模式中不同的组件，然后再来处理映射。上下文部分包含数据，而逻辑部分包含将上下文中数据转换成可读格式的转换逻辑。

上下文和逻辑

让我们看一下日期格式的语法是怎么定义的。定义任何语法的第一步，是把语法分解成小的逻辑组件。图“语法映射与类的映射”展示了怎么识别这些组件，以及怎么映射到处理这部分语法的逻辑类上面。我们已经把日期格式打断成了4个组件，分别是月、日、年和分隔符。对这4个组件，我们将分别定义包含图中展示的逻辑的类。然后，我们将为日期格式的不同组件创建不同的类。

语法映射与类的映射

前面说过，有两种类，一种是包含逻辑的表达式类，另一种是包含数据的上下文类，如图“表达式和上下文类”中所示。我们定义了不同类中的表达式解析算法，这些类都从公共接口“ClsAbstractExpression”派生，并实现了“Evaluate”方法。“Evaluate”方法接收包含数据的上下文类作为参数；它根据表达式逻辑来解析数据。“ClsYearExpression”实例将“YYYY”替换成年份值，而 “ClsMonthExpression”将“MM”替换成月份值，以此类推。

解释器类图

表达式和上下文类

现在，我们有了单独的表达式解析逻辑类，然后我们来看看客户端会如何使用这个逻辑。客户端首先把日期语法格式传递给上下文类。依据日期格式，我们依次向集合中添加表达式实例。如果我们找到了“DD”，我们就添加一个“ClsDayExpression”实例；如果我们找到了“MM”，就添加一个“ClsMonthExpression”实例，等等。最后，我们只需要遍历集合，并调用“Evaluate”函数。所有的 “Evaluate”函数执行完之后，我们就显示结果。

客户端解释器逻辑

你能解释迭代器模式吗？

迭代器模式允许在不暴露内部代码实现的情况下，顺序访问每个元素。让我们来理解一下。假设你有一个记录集合，你需要顺序遍历每条记录，并且需要保持当前访问的位置，那么你需要的正是迭代器模式。这是最普通的设计模式，你会在不知不觉中用到它。在某些程度上，当你使用 “foreach”（它允许我们逐个元素地访问一个集合）时，你就已经在使用迭代器模式了。

迭代器业务逻辑

在图“迭代器业务逻辑”中，我们使用 “clsIterator”类来存放顾客类的集合。我们在“clsIterator”类内部，定义了一个数组，和一个名称为“FillObjects”的方法，这个方法用来加载数组的内容。顾客集合数组是私有的，顾客的数据可以通过数组的下标来访问。因此我们定义了一组公有函数，包含 “getByIndex”（通过指定下表来访问），“Prev”（得到集合中前一个顾客数据），“Next”（得到集合中下一个顾客数据），“getFirst”（得到集合中第一个顾客数据），“getLast”（得到集合中最后一个顾客数据）。

我们只对客户端暴露这些函数。这些函数小心的顺序遍历集合，并能够记忆当前遍历的索引。

下面的图“客户遍历逻辑”说明了该如何使用类“clsIterator”的实例“ObjIterator”，显示下一个、前一个、最后一个、第一个，以及通过索引显示顾客数据。

客户遍历逻辑

你能解释调停者模式吗？

大多数时候，项目中组件间的通讯都很复杂。因此组件间的逻辑关系也变得异常复杂。调停者模式帮助对象间用不互相关联的方式来通讯，从而使复杂度最小化。

调停者模式示例

让我们考虑图“调停者模式示例”，它描述了一个需要使用调停者模式的真实场景。它是一个非常用户友好的接口。它有3个典型的场景。

场景1：当用户在文本框中输入时，应该使添加和清除按钮可用。一旦当文本框中没有文字时，应该禁用添加和清除按钮。

场景1

场景2：当用户点击添加按钮时，文本框内的数据应该被输入到列表框内。一旦数据被输入到列表框，它应该清空文本框的内容，并禁用添加和清除按钮。

场景2

场景3：- 当用户点击清除按钮时，名字文本框内的内容被清空，并禁用添加和清除按钮。

场景3

现在从界面上来看上面几个场景，我们可以推断这些界面之间的交互是多么复杂。下图“组件间复杂交互”显示出了逻辑复杂性。

组件间复杂交互

好了，让我给你们看一个好看的图，即下图“通过调停者简化”。与其组件之间直接通讯，不如通过一个作为调停者的中心组件通讯，调停者组件管理着发送给其他组件的消息，这样逻辑更加优雅和清晰。

通过调停者简化

现在我们来看看代码会是什么样子。我们将使用C#，但是你可以很轻松的把这种思想应用在Java或其他语言上。下图“调停者类”展示了一个调停者类完整的代码概述。

调停者类做的第一件事，是保存拥有复杂通讯的类的引用。因此，我们对外暴露了3个重载的方法“Register”。“Register”方法接收文本框对象和按钮对象为参数。交互场景集中在 “ClickAddButton”，“TextChange”和“ClickClearButton”三个方法上。将根据场景不同，这些方法将管理UI组件的可用与禁用。

调停者类

现在的客户逻辑非常优雅、非常酷。在构造函数中，我们首先将参与复杂通讯的所有组件注册到调停者对象中。然后在每个场景中，我们只需要调用调停者对象的函数。简单地说，当有文本变化时，我们调用调停者对象的 “TextChange”函数；当用户点击添加按钮时，我们调用“ClickAddButton”；当点击清除按钮时，调用 “ClickClearButton”函数。

调停者模式的客户逻辑

你能解释备忘录模式吗？

备忘录模式能够在不破坏封装原则的前提下，获取对象内部状态。备忘录模式帮助我们存储一个对象的快照，它可以在任意时间被恢复。让我们通过实例来理解。考虑图“备忘录示例”，它展示了一个顾客的界面。假设用户开始编辑一条顾客记录，并做了一些修改。然后用户觉得有错误，希望能够恢复到原始的数据。这时备忘录模式就登场了。它帮助我们存储数据的一个备份，并且当用户点击“取消”按钮时，对象能够恢复到它的原始状态。

备忘录示例

让我们尝试用C#来实现刚才所讲的顾客界面。下图是顾客类 “clsCustomer”，它聚合了一个备忘录类“clsCustomerMemento”。备忘录类将保存数据的快照，它是顾客类 “clsCustomer”的精确的复制品（除了方法）。当顾客类“clsCustomer”初始化时，备忘录类也将被初始化。当顾客类数据变化时，备忘录类的快照不变化。“Revert”函数把备忘录的数据写回到主类。

顾客类的备忘录

客户端的代码相当简单。我们创建一个顾客类。一旦遇到问题，我们点击“取消”按钮，调用“Revert”函数，将修改过的数据恢复到备忘录快照的原始数据。图“备忘录客户端代码”形象地展示了这个过程。

备忘录客户端代码

你能解释观察者模式吗？

观察者模式帮助我们与父类，关联类或者依赖类之间进行通讯。观察者模式中，有两个重要的概念，分别是“主体”和“观察者”。主体发送通知，如果观察者已经注册到主体的话，观察者会收到通知。下图“主体和观察者”展示了应用程序（主体）是如何给所有观察者（邮件，事件日志，短消息服务）发送通知的。你可以把这个例子对应到发布者与订阅者模型。发布者就是应用程序，而订阅者是邮件，事件日志和短消息服务。

主体和观察者

让我们尝试对前面定义的示例进行编码。首先我们看一下订阅者/通知者类。图“订阅者类”做了一个直观地展示。对所有的订阅者，我们有一个公共的接口，“INotification”，它有一个 “notify”方法。所有需要接收通知的类，都需要实现这个“INotification”接口。所有需要接收通知的类，定义各自的响应方法。对当前场景，我们只打印一个消息，表明特定的通知被执行了。