第25章  世界需要和平——中介者模式

       中介者模式（Mediator），又称调停者模式，用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。为什么需要中介者模式？因为尽管将一个系统分割成许多对象通常增加了其可复用性，但是对象间相互连接的激增又会降低其可复用性。大量的连接使得一个对象不可能在没有其它对象的支持下工作，系统表现为一个不可分割的整体，所以，对系统的行为进行任何较大的改动就十分困难。而通过中介者模式，每个具体对象不再通过直接的联系与另一个对象发生相互作用，而是通过‘中介者’对象与另一个对象发生相互作用。中介者对象的设计，使得系统的结构不会因为新对象的引入造成大量的修改工作。中介者模式的结构图如下所示。

       其中，Mediator类，表示抽象中介者，定义了一个抽象的发送消息方法，得到同事对象和发送消息；Colleague表示抽象同事类，在其中构造方法，得到中介者对象；ConcreteMediator表示具体中介者对象，实现抽象类的方法，它需要知道所有具体同事类，并从具体同事接收消息，向具体同事对象发出命令；ConcreteClleague表示具体同事类，每个具体同事只知道自己的行为，而不了解其他同事类的情况，但它们却都认识中介者对象。

       中介者模式主要有以下两个优点：（1）Mediator的出现减少了各个Colleague的耦合，使得可以独立地改变和复用各个Colleague，比如任何国家的改变不会影响到其他国家，而只是与安理会发生变化；（2）由于把对象如何协作进行了抽象，将中介作为一个独立的概念并将其封装起在一个对象中，这样关注的对象就从对象各自本身的行为转移到他们之间的交互上来，也就是站在一个更宏观的角度去看待系统。但其存在一个缺点，那就是由于ConcreteMediator控制了集中化，于是就把交互复杂性变为了中介者的复杂性，这就使得中介者会变得比任何一个ConcreteColleague都复杂。

       综合以上中介者模式的结构组成和优缺点， 这个设计模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合，以及想定制一个分布在多个类中的行为，而又不想生成太多的子类的场合。

第26章  项目多也别傻做——享元模式

       享元模式（Flyweight），运用共享技术有效地支持大量细粒度的对象。其结构图如下。

       其中，Flyweight类是所有具体享元类的超类或接口，通过这个接口，Flyweight可以接受并作用于外部状态；ConcreteFlyweight类是继承Flyweight超类或实现Flyweight接口，并为内部状态增加存储空间；UnsharedConcreteFlyweight是指那些不需要共享的Flyweight子类，因为Flyweight接口共享成为可能，但是它并不强制共享；FlyweightFactory是一个享元工厂，用来创建并管理Flyweight对象，它主要是用来确保合理地共享Flyweight，当用户请求一个Flyweight时，FlyweightFactory对象提供一个已创建的实例或者创建一个（如果不存在的话）。
       使用享元模式能带来什么好处呢？享元模式可以避免大量非常相似类的开销。在程序设计中，有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本上都是相同的，有时就能够大幅度的减少需要实例化的类的数量。如果能把那些参数移到类实例的外面，在方法调用时将它们传递进来，就可以通过共享大幅度地减少单个实例的数目。也就是说，享元模式Flyweight执行时所需的状态是有内部的也可能有外部的，内部状态存储于ConcreteFlyweight对象之中，而外部对象则应该考虑由客户端对象存储或计算，当调用Flyweight对象的***作时，将该状态传递给它。

       享元模式的应用。如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用；还有就是对象的大多数状态可以外部状态，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象，此时可以考虑使用享元模式。

第27章  其实你不懂老板的心——解释器模式

       解释器模式（interpreter），给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。解释器模式需要解决的是，如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。其结构图如下所示。

       其中，AbstractExpression（抽象表达式），声明一个抽象的解释***作，这个接口为抽象语法树中所有的节点所共享；TerminalExpression（终结符表达式），实现与文法中的终结符相关联的解释***作。实现抽象表达式中所要求的接口，主要是一个interpreter（）方法。文法中每一个终结符都有一个具体终结表达式与之相对应；NonterminalExpression（非终结符表达式），为文法中的非终结符实现解释***作，对文法中每一条规则R1、R2……Rn都需要一个具体的非终结符表达式类，通过实现抽象表达式的interpreter（）方法实现解释***作，解释***作以递归方式调用上面所提到的代表R1、R2……Rn中各个符号的实例变量；Context，包含解释器之外的一些全局信息。

      通常当有一个语言需呀解释执行，并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。那么，解释器模式有什么好处呢？用了解释器模式，就意味着可以很容易地改变和扩展文法，因为该模式使用类来表示文法规则，你可使用继承来改变或扩展该文法。也比较容易实现文法，因为定义抽象语法树种各个节点的类的实现大体类似，这些类都易于直接编写。解释器模式也有不足的，解释器模式为文法中的每一条规则至少定义了一个类，因此包含许多规则的文法可能难以管理和维护。建议当文法非常复杂时，使用其他的技术如语法分析程序或编译器生成器来处理。

第28章  男人和女人——访问者模式

       访问者模式：表示一个作用于某对象结构中的各元素的***作，它使你可以在不改变各元素的类的前提下定义作用于这些元素的新***作。其结构图如下所示。

       其中，Visitor类，为该对象结构中ConcreteElement的每一个类声明一个Visit***作；ConcreteVisitor类，具体访问者，实现每个由Visitor声明的***作；Element类，定义一个Accept***作，它以一个访问者为参数；ConcreteElementA和ConcreteElementB类，具体元素，实现Accept***作；ObjectStructure类，能枚举它的元素，可以提供一个高层的接口以允许访问者访问它的元素。

       访问者模式适用于数据结构相对稳定的系统，它把数据结构和作用于数据结构上的***作之间的耦合解脱开，使得***作集合可以相对自由地演化。访问者模式的目的是要把处理从数据结构分离出来。很多系统可以按照算法和数据机构分开，如果这样的系统有比较稳定的数据结构，又有易于变化的算法的话，使用访问者模式就是比较合适的，因为访问者模式使得算法***作的增加变得容易。反之，如果这样的系统的数据结构对象易于变化，经常要有新的数据对象增加进来，就不适合使用访问者模式。 访问者模式的优点是增加新的***作很容易，因为增加新的***作就意味着增加一个新的访问者。访问者模式将有关的行为集中到一个访问者对象中。访问者模式的缺点其实也就是使得增加新的数据结构变得困难了。

第29章  OOTV杯超级模式大赛——模式总结

       本章对整书做了一个总结，对书中介绍的设计模式进行概括分析，并且根据不同的模式对设计模式进行了分类，主要有以下3大类：（1）创建型模式，包含的设计模式有抽象工厂模式、建造者模式、工厂方法模式、原型模式和单例模式；（2）结构型模式，包含的设计模式有适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和***模式；（2）行为型模式，包含的设计模式有观察者模式、模板方法模式、命令模式、状态模式、职责链模式、解释器模式、中介者模式、访问者模式、策略模式、备忘录模式以及迭代器模式。对这些设计模式的结构、适用场合、优缺点内存等方面均做了介绍和对比，让我们对众多的设计模式有了一个清晰的认识，可以根据它们的特点选择合适的设计模式，更高效的解决遇到的问题。

全书总结

       本书用小说的形式讲解了设计模式的奥妙，是初学者的快速入门的宝典。书中对每个设计模式的讲解都从实际生活中的例子出发，容易引起读者的兴趣，在深入介绍具体设计模式的实现时更生动，结合实例也让读者更容易理解，学起来不会像其他书籍那样显得枯燥。本书的特色是通过小菜与大鸟的趣味问答，在讲解程序的不断重构和演变过程中，把设计模式的学习门槛降低，让初学者可以更加容易地理解。