设计模式总结八（享元模式、解释器模式和访问者模式）

前言

这是《大话设计模式》总结最后一篇博文了，对设计模式的学习也暂告一段落，接下来我来总结最后三个设计模式：享元模式、解释器模式和访问者模式。

享元模式

本章是第26章，作者先写了小菜和大鸟的对话：“如果有100家企业找你做网站，你难道申请100个空间，用100个数据库，然后用类似的代码复制100遍，去实现吗？这样维护量太大了。”

“首先，这些客户的网站结构相似度应该很高，而且网站访问量也不会很大，如果分成多个虚拟空间来处理，相当于一个相同网站的实例对像很多，这将造成服务器大量资源浪费和钱财浪费。如果整合到一个网站中，用少量的服务器资源，而对于代码，由于是一份实例，维护和扩展都更加容易。”

我们可以通过享元模式来实现上述的想法。享元模式的概念如下：

享元模式运用共享技术有效地支持大量细粒度的对象。

享元模式地结构图如下：

享元模式的优点是可以避免大量非常相似类地开销。在程序设计中，有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本都是相同的，有时就能够受大幅度地减少需要实例化类的数量。如果能把那些参数移到类实例的外面，在方法调用时将他们传递进来，就可以大幅度的减少单个实例的数目。如果一个应用程序使用了大量对象，而这些大量对象造成了很大的存储开销时就应该考虑使用，还有就是对象的大多数状态可以是外部状态，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象，此时可以考虑使用享元模式。

解释器模式

本章是第27章，作者通过老板加薪的案例，单刀直入，在开头就写出解释器模式的定义：

解释器模式给定一个语言，定义他的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子

接着大鸟说：“如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。”例如正则表达式就是有个很好的例子。（正好现在学校里还在学《计算理论导引》，我就想到了非确定有穷自动机和正则语言）

解释器模式的结构图如下所示：

解释模式在当一个语言需要解释执行，并且你可将该语言中的句子表示为一个抽象的时候推荐使用。

访问者模式

书中指出，访问者模式适用于数据结构相对稳定的系统，它们将数据结构和作用余结构上的操作之间的耦合解脱开来，使得操作集合可以相对自由的演化。访问者模式的目的是要把处理数据的步骤从数据结构的代码中分离出来。如果有比较稳定的数据结构又有易于变化的算法的话，使用访问者模式就是比较适合的，因为访问者模式在算法增加后，也一样容易操作。因为增加新的操作就意味着增加一个新的访问者。访问者模式将有关的行为集中到一个访问者对象中。

访问者模式定义如下：

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

END