软考面向对象程序设计复习指南

Posted 2021-12-05 小哈里

1、根据考纲

（1）分析模式与设计模式知识
（2）面向对象程序设计知识
（3）用C++语言实现常见的设计模式及应用程序。
（4）用Java语言实现常见的设计模式及应用程序。

2、面向对象基本概念

面向对象开发方法与结构化开发有着本质的差异，这种方法引入了“对象”的概念，将数据和方法封装在一起，提高了模块的聚合度，降低
了耦合度， 更大程度上支持软件复用。是现在最流行和最具有发展前景的软件开发方法。在了解该方法的具体内容之前，需要对面向对象的一系列概念有所了解。
下面介绍考试中，经常会考到一系列面向对象的基本概念。

（1）对象
在计算机系统中，对象是指一组属性及这组属性上的专用操作的封装体，它由对象标识（名称）、属性（状态、数据、成员变量，也可以是另一个对象）和服务（操作、行为、方法）三个要素组成 。对象是系统中用来描述客观事物的一个实体，它们被封装为一个整体，以接口的形式对外提供服务。

（2）类
类是一组具有相同属性和方法的对象的集合 。一个类中的每个对象都是这个类的一个实例（instance）。在系统分析和设计时，通常要把注意力集中在类上，而不是具体的对象上。
每个类一般都有实例**，没有实例的类是抽象类** 。抽象类不能被实例化 （不能用new关键字去产生对象），抽象方法只需声明，而不需实现。是否建立了丰富的类库 是衡量一个OO程序设计语言成熟与否的重要标志之一。

（3）继承与泛化
继承是面向对象方法中重要的概念，用来说明特殊类（子类）与一般类（父类）的关系 ，
通常使用泛化来说明一般类与特殊类之间的关系 ，它们之间是一对多关系。

（4）封装。
面向对象系统中的封装单位是对象 ，对象之间只能通过接口进行信息交流 ，对象外部不能对对象中的数据随意地进行访问。
封装的目的是使对象的定义和实现分离 ，这样，就能减少耦合 ，类内部的实现可以自由改变而不会影响其他的类或对象。
同时，类具有严密的接口保护，使对象的属性或服务不会随意地被使用 ，对象的状态易于控制，可靠性随之增强。

（5）多态性
多态（多种形式）性则是指一般类中定义的属性或服务被特殊类继承后 ，可以具有不同的数据类型或表现出不同的行为，通常是使用重载和改写两项技术来实现的。

（6）模板类
模板类也称为类属类，它用来实现参数多态机制 。一个类属类是关于一组类的一个特性抽象 ，它强调的是这些类的成员特征中与具体类型无关的那些部分，而用变元来表示与具体类型有关的那些部分。

（7）消息和消息通信
消息就是向对象发出的服务请求 ，它通常包括提供服务的对象标识、消息名、输入信息和回答信息 。
消息通信则是面向对象方法学中的一个重要原则 ，它与对象的封装原则密不可分 ，为对象间提供了唯一合法的动态联系的途径

3、设计模式

1. 什么是设计模式
   设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式可以提高代码复用度、让代码更容易被他人理解、保证代码可靠性。毫无疑问，设计模式于己、于他人、于系统都是有利的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。

2. 设计模式的组成
   一般来说，一个模式有4个基本成分 ，分别是模式名称、问题、解决方案和效果。
   （1）模式名称
   每个模式都有一个名字，帮助我们讨论模式和它所给出的信息。模式名称通常用来描述一个设计问题、它的解法和效果，由一到两个词组成。模式名称的产生使我们可以在更高的抽象层次上进行设计并交流设计思想。
   （2）问题
   问题告诉我们什么时候要使用设计模式 、解释问题及其背景。例如，MVC（Model-View-Controler，模型-视图-控制器）模式 关心用户界面经常变化的问题 。它可能描述诸如如何 将一个算法表示成一个对象这样的特殊设计问题 。在应用这个模式之前，也许还要给出一些该模式的适用条件。
   （3）解决方案
   解决方案描述设计的基本要素，它们的关系、各自的任务以及相互之间的合作 。解决方案并不是针对某一个特殊问题而给出的。设计模式提供有关设计问题的一个抽象描述以及如何安排这些基本要素以解决问题 。—个模式就像一个可以在许多不同环境下使用的模板，抽象的描述使我们可以把该模式应用于解决许多不同的问题。
   模式的解决方案部分给出了如何解决再现问题，或者更恰当地说是如何平衡与之相关的强制条件。在软件体系结构中，这样的解决方案包括两个方面。
   第一，每个模式规定了一个特定的结构，即元素的一个空间配置。例如，MVC模式的描述包括以下语句：“把一个交互应用程序划分成三部分，分别是处理、输入和输出”。
   第二，每个模式规定了运行期间的行为。例如，MVC模式的解决方案部分包括以下陈述：“控制器接收输入，而输入往往是鼠标移动、点击鼠标按键或键盘输入等事件。事件转换成服务请求，这些请求再发送给模型或视图”。
   （4）效果
   效果描述应用设计模式后的结果和权衡。比较与其他设计方法的异同，得到应用设计模式的代价和优点。对于软件设计来说，通常要考虑的是空间和时间的权衡。也会涉及到语言问题和实现问题。对于一个面向对象的设计而言，可重用性很重要，效果还包括对系统灵活性、可扩充性及可移植性的影响。明确看出这些效果有助于理解和评价设计模式。

3. 设计模式的分类
   在设计模式概念提出以后，很多人把自己的一些成功设计规范成了设计模式 ，一时间提出了许许多多的模式，但这些模式并没有都为众人所接受，成为通用的模式。直到ErichGamma在他的博士论文中总结了一系列的设计模式，做出了开创性的工作。他用一种类似分类目录的形式将设计模式记载下来。我们称这些设计模式为设计模式目录。
   根据模式的目标（所做的事情） ，可以将它们分成创建性模式（creational）、结构性模式（structural）和行为性模式（behavioral）。创建性模式处理的是对象的创建过程，结构性模式处理的是对‘’象/类的组合，行为性模式处理类和对象间的交互方式和任务分布。根据它们主要的应用对象，又可以分为主要应用于类的和主要应用于对象的。
   表15-1是ErichGamma等人总结的23种设计模式， 这些设计模式通常被称为GoF（Gang ofFour，四人帮）模式。因为这些模式是在《Design Patterns: Elements of Reusable Object-Oriented Software》中正式提出的，而该书的作者是Erich Gamma、Richard Helm、RalphJohnson 和 John Vlissides，这几位作者常被称为“四人帮”。
   表15-1设计模式目录的分类
   
   
   
   其中带*为关于类的，其他是关于对象的。
   在后面的章节中，我们将详细论述23种模式的特点、应用场合及UML图。

4、常用设计模式详解

1. 简单工厂模式
   简单工厂（Simple Factory）专门定义一个类的实例，被创建的实例通常都具有共同的父类 。简单工厂模式又称为静态工厂方法（Static Factory Method）模式，属于创建型模式，通常它根据自变量的不同返回不同类的实例。简单工厂模式的实质是由一个工厂类根据传入的参量，动态决定应该创建出哪一个产品类的实例。简单工厂模式实际上不属于GoF的23个模式，但它可以作为GoF的工厂方法模式（Factory
   Method）的一个引导。其UML类模型如图15-1所示，其涉及的参与者有三个：工厂角色、抽象产品角色和具体产品角色。
   工厂（Creator）角色：是简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用，创建所需的产品对象。抽象产品（Product）角色：是简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。具体（ConcreteProduct）角色：是简单工厂模式的创建目标，所创建的对象都是充当这‘’个角色的某个具体类的实例。

2. 工厂方法模式
   工厂模式（Factory）又称为工厂方法模式，也叫虚拟构造函数（Virtual Constructor）模式或者多态工厂模式 。在工厂模式中，父类负责定义创建对象的公共接口，而子类则负责生成具体的对象 ，这样做的目的是将类的实例化操作延迟到子类中完成，即由子类来决定究应该实例化哪一个类。
   在简单工厂模式中，一个工厂类处于对产品类进行实例化的中心位置 ，它知道每个产品类的细节，并决定何时哪一个产品类应当被实例化。简单工厂模式的优点是能够使客户端独立于产品的创建过程，并且在系统中引入新产品时无须对客户端进行修改，缺点是当有新产品要加入到系统中时，必须修改工厂类，以加入必要的处理逻辑。简单工厂模式的致命弱点就是处于核心地位的工厂类，因为一旦它无法确定要对哪个类进行实例化，就无法使用该模式，而工厂方法模式则可以很好地解决这一问题。工厂方法模式的UML类图的如图15-2所示。
   其中的类或对象之间的关系为：
   产品（Product）角色：定义产品的接口。
   真实产品（ConcreteProduct）角色：实现接口Product的类。
   工厂（Creator）角色：声明工厂方法（FactoryMethod），返回一个产品。
   真实工厂（ConcreteCreator）角色：实现工厂方法（FactoryMethod），则客户调用，返回
   一个产品的实例。
   图15-2工厂模式的UML类模型

3. 抽象工厂
   抽象工厂提供了一个创建一系列相关或相互依赖对象的接口 ，而无须指定它们具体的类。抽象工厂（Abstract Factory）模式又称为Kit模式，属于对象创建型模式。
   抽象工厂模式与工厂模式最大的区别在于：工厂模式针对的是一个产品的等级结构，而抽象工厂模式则针对的是多个产品等级结构 。正因为如此，在抽象工厂模式中经常会用到产品族这一概念，它指的是位于不同的产品等级结构中，并且功能相互关联的产品系列。其UML类模型如图15-3所示。其中的类或对象之间的关系为：
   抽象工厂（AbstractFactory）：声明生成抽象产品的方法。
   具体工厂（ConcreteFactory）：执行生成抽象产品的方法，生成一具体的产品。
   图15-3抽象工厂模式的UML类模型
   类和对象之间的关系为：单例（Singleton）：提供一个instance方法，让客户可以使用它的唯一实例。内部实现只生成一个实例。

4. 构建模式
   构建（Builder）模式将把一个复杂对象的构建与它的表示分离 ，使得同样的构建过程可以创建不同的表示。
   构建模式是一步步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不知道内部的具体构建细节UML类模型如图8-7所示。
   其中的类或对象之间的关系为：
   抽象构建者（Builder）：为创建一个Product对象的各个部件指定抽象接口。
   具体构建者（ConcreteBuilder）：实现Builder接口，构造和装配产品的各个部件；定义并明确它所创建的表示；提供一个返回这个产品的接口。
   指挥者（Director）：构建一个使用Builder接口的对象。
   产品（Product）：被构建的复杂对象，具体构建者创建该产品的内部表示并定义它的装配过程；包含定义组成部件的类，包括将这些部件装配成最终产品的接口。

5. 原型模式
   原型（Prototype）模式指定创建对象的种类 ，并且通过复制这些原型创建新的对象 。
   原形模式允许一个对象再创建另一个可定制的对象，根本无须知道任何创建的细节。工作原理是：通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象复制自己来实施创建过程。
   UML类模型如图15-6所示。 图15-6原型模式的UML类模型
   其中类和对象之间的关系为：
   抽象原型（Prototype）类：定义具有克隆自己的方法的接口。
   具体原型（ConcretePrototype）类：实现具体的克隆方法。
   客户（Client）类：通过克隆生成一个新的对象。

6. 适配器模式
   适配器（Adapter）模式将一个接口转换成为客户想要的另一个接口 ，适配器模式使接口不兼容的那些类可以一起工作。其UML类模型如图15-7所示。
   其中类的定义及其关系如下：
   目标抽象（Target）类：定义客户要用的特定领域的接口。
   适配器公接口（Adapter）：调用另一个接口，作为一个转换器。
   适配器母接口（Adaptee）：Adapter需要接入。
   客户调用（Client）类：协同对象符合Adapter适配器（公接口）。

7. 合成模式
   合成（Composite）模式组合多个对象形成树型结构 以表示整体—部分的结构层次。合成模式对单个对象和合成对象的使用具有一致性。其UML类模型如图15-8所示。
   其中类和对象的关系如下：
   部件抽象接口（Component）：为合成的对象声明接口；某些情况下，实现从此接口派生出所有类共有的默认行为；定义一个接口可以访问及管理它的多个部分（GetChild）；如果必要也可以在递归结构中定义一个接口访问它的父节点，并且实现它。叶子部件（Leaf）：在合成中表示叶节点对象，叶节点没有子节点；定义合成中原接口对象的行为。
   合成（Composite）类：定义有子节点（子部件）的部件的行为；存储子节点（子部件）；在Component接口中实现与子部件相关的操作。
   客户（Client）应用程序：通过Component接口控制组合部分的对象。

8. 装饰模式
   装饰（Decorator）模式动态地给一个对象增加其他职责 ，就增加对象功能来说，装饰模式比生成子类实现更为灵活。UML类模型如图15-9所示。
   其中类和对象的关系为：
   部件（Component）：定义对象的接口，可以给这些对象动态增加职责（方法）。
   具体部件（Concrete Component）：定义具体的对象，Decorator可以给它增加额外的职责
   （方法）。
   装饰抽象（Decorator）类：维护一个内有的Component，并且定义一个与Component接口
   一致的接口。
   具体装饰对象（ConcreteDecorator）：为内在的具体部件对象增加具体的职责（方法）。

9. 代理模式
   代理（Proxy）模式为其他对象提供一个代理或地方以控制对这个对象的访问 。当客户向代理对象第一次提出请求时，将实例化为真实的对象，并且将请求传给它，以后所有的客户请求都经由proxy传给封装了的真实对象。其UML类模型如图15-10所示。
   图15-10代理模式的UML类模型
   其中的类和对象的关系为：
   代理（Proxy）：维护一个引用使得代理可以访问实体，如果RealSubject和Subject的接口相同，Proxy会引用Subject；提供一个与Subject的接口相同的接口，使得代理可以用来替代实体，这与适配器模式类似；控制对实体的访问并且负责创建及删除它。
   抽象实体（Subject）接口：为RealSubject实体及Proxy代理定义相同的接口中，使得RealSubject在任何地方都可以使用Proxy来访问。
   实体（RealSubject）：定义Proxy代理的实体。

10. 享元模式
    享元（Flyweight）模式运用共享技术有效地支持大量细粒度的对象 。系统只使用少量的对象，而这些对象都相近、状态变化很小、对象使用次数较多。其UML类模型如图15-11所示。
    其中类和对象的关系为：
    享元（Flyweight）类：声明一个接口，通过它可以接收外来的参数（状态），并对新状态做出处理（作用）。
    具体享元（ConcreteFlyweight）类：实现Flyweight的接口，并为内部增加存储空间。ConcreteFlyweight对象必须是可以共享的，它所存储的状态必须是内部的，即它独立存在于自己的环境中。
    不共享的具体享元（UnsharedConcreteFlyweight）类：不是所有的Flyweight子类都需要被共享，Flyweight的共享不是强制的。在某些Flyweight的结构层次中，UnsharedConcreteFlyweight对象通常将ConcreteFlyweight对象作为子节点。
    享元类工厂（FlyweightFactory）：创建并管理flyweight对象；确保享用flyweight，当用户请求一个flyweight对象时，FlyweightFactory提供一个已创建的实例或者创建一个实例（如果不存在）。
    客户应用程序（Client）：维持一个对flyweight的引用；计算或存储一个或多个flyweight的外部状态。

11. 门面模式
    门面（Facade）模式也称为外观模式 ，提供一个统一的接口去访问多个子系统的多个不同的接口 。门面模式定义了一个高层次的接口，使得子系统更容易被使用。其UML类模型如图15-12所示。
    图15-12门面模式的UML类模型
    其中类和对象的关系为：
    门面（Facade）类：知道哪些子系统负责处理哪些请求；将客户的请求传递给相应的子系统对象处理。
    子系统（Subsystem）类：实现子系统的功能；处理由Facade传过来的任务；子系统不用知道Facade，在任何地方都没有引用Facade。

12. 桥接模式
    桥接（Bridge）模式将抽象部分与实现部分分离 ，使得它们两部分可以独立地变化 。
    其UML类模型如图15-13所示。其中类和对象的关系为：图
    抽象（Abstraction）类：定义抽象类的接口，维护一个实现抽象（Implementor）的对象。
    扩充抽象（RefinedAbstraction）类：扩充由Abstraction定义的接口。
    实现（Implementor）类接口：定义实现类的接口，这个接口不一定要与Abstraction的接口完全一致，事实上这两个接口可以完全不同，一般地讲Implementor接口仅提供基本操作，而Abstraction定义的接口可能会做更多更复杂的操作。
    具体实现（ConcreteImplementor）类：具体实现Implementor的接口。

13. 策略模式
    策略（Strategy）模式定义一系列的算法，将每一个算法封装起来，并让它们可以相互替换 。策略模式让算法独立于使用它的客户而变化。其UML类模型如图15-14所示。
    图15-14策略模式的UML类模型 其中类和对象的关系为：
    抽象策略（Strategy）类：定义一个公共的接口给所有支持的算法，Context使用这个接口调用ConcreteStrategy定义的算法。
    具体策略（ConcreteStrategy）类：调用StraStrategy接口实现具体的算法。上下文（Context）：用ConcreteStrategy对象配置其执行环境；维护一个对Strategy的引用实例；可以定义一个接口供Strategy存取其数据。

14. 模板方法模式
    模板方法（Template Method）模式定义一个操作中算法的骨架 ，以将一些步骤延缓到子类中实现。模板方法让子类重新定义一个算法的某些步骤而无须改变算法的结构。
    其UML类模型如图15-15所示。 图15-15模板方法模式的UML类模型
    其中类和对象的关系为：
    抽象（AbstractClass）类：定义一个抽象原始的操作，其子类可以重定义实现算法的各个步骤；实现一个模板方法定义一个算法的骨架，此模板方法不仅可以调用原始的操作，还可以调用定义于AbstractClass中的方法或其他对象中的方法。
    具体（ConcreteClass）类：实现原始的操作以完成子类特定算法的步骤。

15. 迭代器模式
    迭代器（Iterator）模式提供一种方法可以访问聚合对象 ，而不用暴露这个对象的内部表示。
    其UML类模型如图15-16所示。图15-16迭代器模式的UML类模型 其中类和对象的关系为：
    迭代器（Iterator）：定义访问和遍历元素的接口。
    具体迭代器（ConcreteIterator）：实现迭代器的接口；在遍历时跟踪当前聚合对象中的位置。
    聚合（Aggregate）：定义一个创建迭代器对象的接口。
    具体聚合（ConcreteAggregate）：创建迭代器对象，返回一个具体迭代器实例。

16. 责任链模式
    责任链（Chain of Responsibility）模式能避免请求发送者与接收者耦合在一起 ，让多个对象都有可能接收接求 ，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理为止。
    该模式的UML类模型如图15-17所示。 图15-17责任链模式的UML类模型
    其中类和对象的关系：
    传递者（Handler）接口：定义一个处理请求的接口；或实现链中下一个对象。
    具体传递者（ConcreteHandler）：处理它所负责的请求；可以访问链中下一个对象；如果可
    以处理请求，就处理，否则将请求转发给后继者。
    客户应用程序（Client）：向链中的对象提出最初的请求。

17. 命令模式
    命令（Command）模式将一个请求封装成一个对象，因此可以参数化多个客户的不同请求，将请求排队，记录请求日志，并且支持撤销操作。
    其UML类模型如图15-18所示。 图15-18命令模式的UML类模型
    其中类和对象之间的关系为：
    抽象命令（Command）类：声明执行操作的一个接口。
    具体命令（ConcreteCommand）类：将一个接收者对象绑定于一个动作；实现Execute方法，以调用接收者的相关操作（Action）。
    客户应用程序（Client）：创建一个具体命令类的对象，并且设定它的接收者。
    调用者（Invoker）：要求一个命令对象执行一个请求。
    接收者（Receiver）：知识如何执行关联请求的相关操作。

18. 备忘录模式
    备忘录（Memento）模式在不破坏封装的前提下，捕获并且保存一个对象的内部状态， 这样可以将对象恢复到原先保存的状态。
    其UML类模型如图15-19所示。 图15-19备忘录模式的UML类模型
    其中类和对象的关系为：
    备忘录（Memento）：保持Originator（原发器）的内部状态，根据原发器来决定保存哪些内部的状态；保护原发器之处的对象访问备忘录，备忘录可以有效地利用两个接口，看管者只能调用狭窄（功能有限）的接口，即只能传递备忘录给其他对象，而原发器可以调用一个宽阔（功能强大）的接口，通过这个接口可以访问所有需要的数据，使原发器可以返回先前的状态。理想的情况是，只允许生成本备忘录的那个原发器访问本备忘录的内部状态。
    原发器（Originator）：创建一个备忘录，记录它的当前内部状态；可以利用一个备忘录来恢复它的内部状态。
    看管者（Caretaker）：只负责看管备忘录；不可以对备忘录的内容操作或检查。
    图15-20未采用备忘录模式时的UML类模型
    Memento模式经常在很多应用软件出现，按Ctrl-Z会取消最后一次用户操作。如果不用Memento模式，Caretaker对象要备份Originator对象的状态，Originator就要具有所有需要访问成员的方法，当要恢复Originator对象的状态时，Caretaker更要清楚Originator内部的结构。这种
    严紧的凝结的结果是，发生在Originator上的任何修改，Caretaker都要作出相应的修改，这样就打破了对象封装的特点。图15-20是没有采用Memento模式时的结构。
    而Memento模式是解决这种问题的最好办法，Memento类成了Originator及Caretaker的媒介，封装保存Originator的备份状态，当Originator被提出备份请求时，它就会创建一个Memento对象返回给Caretaker。Caretaker不可以看到Memento对象的内部信息，需要时Caretaker可以返回备份的Memento对象给Originator，让它恢复到备份状态。结构如图15-21所示。

19. 状态模式
    状态（State）模式能够使一个对象的内在状态改变时允许改变其行为 ，使这个对象看起来像是改变了其类。
    该模式的UML类模型如图15-22所示。 图15-22状态模式的UML类模型
    其中类和对象的关系为：
    上下文（Context）类：定义客户应用程序有兴趣的接口；维护一个ConcreteState（具体状态）子类的实例对象。
    抽象状态（State）类：定义一个接口以封装与Context的一个特别状态（State）相关的行为。
    具体状态（ConcreteState）类：每一个具体状态类实现一个Context的状态相关的行为。

20. 访问者模式
    访问者（Visitor）模式说明一个操作执行于一个对象结构的成员中 。访问者模式让你定义一个类的新操作而无须改变它操作的这些成员类。
    UML类模型如图15-23所示。图15-23访问者模式的UML类模型
    其中类和对象的关系为：
    抽象访问者（Visitor）：为对象结构类中的每一个ConcreteElement的类声明一个Visit操作，这个操作的名称及标志（signature）识别传出Visit请求给访问者的类。这就使得访问者可以找到被访问的元素的具体类，也就可以直接经由其特有接口访问到元素（Element）。
    具体访问者（ConcreteVisitor）：实现每个由Visitor声明的操作，每个操作实现本算法的一部分，而该算法片断乃是对应于结构中对象的类。ConcreteVisitor为该算法提供了场境并存储它的局部状态。这一状态常常在遍历该结构的过程中累积结果。
    元素（Element）：定义一个Accept操作，它以一个访问者为参数。
    具体元素（ConcreteElement）：实现Accept操作，该操作以访问者为参数。
    对象结构（ObjectStructure）类：能枚举它的元素；可以提供一个高层的接口以允许访问者访问它的元素；可以是一个合成模式或是一个集合，如一个列表或一个无序集合。

21. 解释器模式
    给出一种语言，定义这种语言的文法的一种表示，定义一个解释器（Interpreter），用它来解释使用这种语言的句子，这就是解释器模式，
    其UML类模型如图15-24所示。图15-24解释器模式的UML类模型 其中类和对象之间的关系为：
    抽象表达式（AbstractExpression）类：定义一个接口来执行解释操作。
    终结符表达式（TerminalExpression）：实现文法中关联终结符的解释操作；文句中的每个终结符都需要一个实例。
    非终结符表达式（NonTerminalExpression）：文法中的每一条规则R::=R1R2…Rn都需要一个
    非终结符表达式类；维护每一条规则R1到Rn具有AbstractExpression接口实例；实现文法中关联非终结符的解释操作，采用递归的办法调用每一条规则R1到Rn的解释操作。上下文（Context）：包括解释器的所有全局信息。
    客户应用程序（Client）：构建由这种语言表示的句子的抽象文法树，文法树由终结符表达式或者非终结符表达式的实例组成；调用文法树中的表达式实例的解释操作。

22. 调停者模式
    调停者（Mediator）模式定义一个对象封装一系列多个对象如何相互作用 。Mediator使得对象之间不需要显式地相互引用，从而使其耦合更加松散。并且还让我们可以独立变化多个对象相互作用，
    其UML类模型如图15-25所示。其中类和对象的关系为：
    抽象调停者（Mediator）：定义一个接口用于与各同事对象（Colleague）之间通信。
    具体调停者（ConcreteMediator）：协调各个同事对象实现协作的行为；掌握并且维护它的各个同事对象引用。
    同事（Colleague）类：每一个同事对象都引用一个调停者对象；每一个同事对象在需要和其他同事对象通信时，就与它的调停者通信。
    图15-25调停者模式的UML类模型

23. 观察者模式
    观察者（Observer）模式定义对象间的一种一对多依赖关系，使得每当一个对象改变状态，则其相关依赖对象皆得到通知并被自动更新 ，其UML类模型如图15-26所示。
    其中类和对象的关系为：
    被观察对象（Subject）：了解其多个观察者，任意数量的观察者可以观察一个对象；提供一个接口用来绑定及分离观察者对象。
    具体被观察对象（ConcreteSubject）：存储具体观察者（ConcreteObserver）有兴趣的状态；当其状态改变时发送一个通知给其所有的观察者对象。观察者（Observer）：定义一个更新接口，在一个被观察对象改变时应被通知。
    具体观察者（ConcreteObserver）：维护一个对ConcreteSubject对象的引用；存储状态，状态需与ConcreteSubject保持一致；实现观察者更新接口以保持其状态与ConcreteSubject对象一致。

MVC基础

MVC模式是“Model-View-Controller”的缩写，中文翻译为 “模式-视图-控制器” 。它把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层—— 模型层、视图层、控制层 。

• 视图（View）代表用户交互界面 ，对于Web应用来说，可以概括为html界面，但有可能为XHTML、XML和Applet。而一个应用可能有很多不同的视图，MVC设计模式对于视图的’处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理，业务流程的处理交予模型（Model）处理。
• 模型（Model）：就是业务流程/状态的处理以及业务规则的制定 。业务流程的处理过程对其他层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保存（持续化）。
• 控制（Controller）可以理解为从用户接收请求，将模型与视图匹配在一起 ，共同完成用户的请求 。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。
• 模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果 用户通过某个视图的控制器改变了模型的数据 ，所有其他依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制 。