访问者模式

面临问题：

在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为(方法)，如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计。

如何在不改变类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题？

解决方案：

为了把一个操作作用于一个对象结构中，一种做法是把这个操作分散到每一个节点上，导致系统难以理解、维护和修改。改进方案是把这样的操作包装到一个独立的对象(visitor)中。然后在遍历过程中把此对象传递给被访问的元素。

也就是说：一个项目的基本功能已经确定下来，元素类的数据已经基本确定下来不会变了，会变的只是这些元素内的相关操作，这时候，我们可以使用访问者模式对原有的代码进行重构一遍，这样一来，就可以在不修改各个元素类的情况下，对原有功能进行修改。其功能实现在具体visitor中实现。

 Visitor(抽象访问者) 为该对象结构中ConcreteElement的每一个类声明一个Visit操作。该操作的名字和特征标识了发送Visit请求给该访问者的那个类。这使得访问者可确定正被访问元素的具体的类。这样访问者就可以通过该元素的特定接口直接访问它。 ConcreteVisitor(具体访问者)实现每个由Visitor声明的操作。每个操作实现本算法的一部分，而该算法片断乃是对应于结构中对象的类。 ConcreteVisitor为该算法提供了上下文并存储它的局部状态。这一状态常常在遍历该结构的过程中累积结果。 Element(抽象元素) 定义一个Accept操作，它以一个访问者为参数。 ConcreteElement(具体元素) 实现Accept操作，该操作以一个访问者为参数。 ObjectStructure(对象结构) 能枚举它的元素。 可以提供一个高层的接口以允许该访问者访问它的元素。 可以是一个复合或是一个集合

数据结构的每一个节点都可以接受一个访问者的调用，此节点向访问者对象传入节点对象，而访问者对象则反过来执行节点对象的操作。这样的过程叫做"双重分派"。节点调用访问者，将它自己传入，访问者则将某算法针对此节点执行。

访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易（就是增加对这个数据结构的操作），就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。

把操作的实现定义在了vistior里了，所以要想增加一种功能，只要增加一个visitor实现类就可以了。而在数据结构中有一个接受visitor的方法，实现双重分派。

相关模式：

Composite：访问者可以用于对一个由Composite模式定义的对象结构进行操作。Interpreter：访问者可以用于解释。

访问者模式的适用场景

       假如一个对象中存在着一些与本对象不相干（或者关系较弱）的操作，为了避免这些操作污染这个对象，则可以使用访问者模式来把这些操作封装到访问者中去。

       假如一组对象中，存在着相似的操作，为了避免出现大量重复的代码，也可以将这些重复的操作封装到访问者中去。

       但是，访问者模式并不是那么完美，它也有着致命的缺陷：增加新的元素类比较困难。通过访问者模式的代码可以看到，在访问者类中，每一个元素类都有它对应的处理方法，也就是说，每增加一个元素类都需要修改访问者类（也包括访问者类的子类或者实现类），修改起来相当麻烦。也就是说，在元素类数目不确定的情况下，应该慎用访问者模式。所以，访问者模式比较适用于对已有功能的重构，比如说，一个项目的基本功能已经确定下来，元素类的数据已经基本确定下来不会变了，会变的只是这些元素内的相关操作，这时候，我们可以使用访问者模式对原有的代码进行重构一遍，这样一来，就可以在不修改各个元素类的情况下，对原有功能进行修改。