《设计模式》笔记： 访问者模式

1.简介

目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构则可以保持不变。

2.问题的起源：

我们有如上图的类结构。现在的需求是：

Element和ConcreteElementA，ConcreteElementB的类结构是很稳定的。但是要经常更改类操作Operate*()。比如说增加一个Operate3，删除Operate1等等。这样的话，子类和父类都要更改。

3.解决办法：解耦类结构和类操作

把类操作封装成另一族类Operator。将原来的类操作视为是Operator（也就是Visitor）对Element对象的访问。Element现在只需定义一个类操作。就是Accept这个神奇的方法。为什么说Accept神奇呢，因为它用到了双委派（double-dispatch）技术。



对于C++这个原生只支持单委派（single-dispatch）的语言而言：其一个多态方法在编译的时候选择哪种实现只取决于该方法的一个参数的类型，这个参数就成类方法隐藏的this指针。而支持双委派的语言中，类方法具体实现的选择可以取决于类方法的两个参数。

我们看accept这个方法，它实际上有两个参数，一个是element *this指针，另一个是operator *op。编译器会根据this的类型选择ConcreteElementA的accept实现或是ConcreteElementB的accept实现（这决定了op调用哪个方法函数VisitConcreteElement*）。但accept的实现也取决于op的类型，编译器不能为我们做选择，而我们要显式地对opertor类再做一次single-dispatch实现这一点：

{ op->VisistConcreteElement*(this); }

可见，accept的双委派实际上是由两个单委派制造的“伪双委派”。



再看是如何解耦的：

原来的函数调用：ConcreteElementX.operateN；

现在的函数调用：OperatorN.vistiConcreteElementX(ConcreteElementX* this) <=> ConcreteElementX.accept(OperatorN *op)

现在，可以在完全不用更改ConcreteElement*类的前提下更改对其的操作。

4.用一个容器类来包含复杂的数据结构

实际中，数据结构不仅是一两个简单的ConcreteElement对象，而可能是多个不同的ConcreteElement的组合（Composite模式）。所以有必要用容器类来封装这些结构。这使得ObjectStructure类有了必要。通常ObjectStructure只是一个vector<element *>或是list<element *>的一层简单封装即可。它也有一个Accept方法，就是枚举容器中每个ConcreElement的Accept操作。

最后献上访问者模式的UML图：