假如我们已经有了一组继承体系：
如果我们要在其中增加一个新的动物mouse，只用新建一个Mouse类，让它继承自公共父类Animal然后覆写run方法即可。得益于对开放封闭原则(OCP)的遵守，老鼠的出现不会惊动到猫狗：）
但是假如我们想要为其增加一个void cry()虚接口呢？这时我们就要打开每个类的文件，为其编写cry的具体实现。这时我们发现了“散弹式修改”的坏味道，一声cry让所有的动物都鸡飞狗跳。我们希望还能像之前那样，当变化来临时所有的修改都能集中在一起。
然而事实是：没有绝对的开放封闭，只有面对具体变化方向的开放封闭！如上的继承体系面对动物种类变更时保持了开放封闭，而面临新的虚接口变更时，却要大范围修改。假如我们的继承体系很稳定，子类的种类发生变化的可能性很低，但是虚接口的变化可能性却很大，那么如何设计才能继续保持开放封闭性？
可以发现，我们手里有一个不需要的优势：方便地添加新的子类；同时也拥有一个令人烦恼的缺点：难以添加新的虚函数。而这正是Visitor设计模式的用武之地，它将所有的虚接口放在一起重新组织出了一个继承体系，然后采用“双向派发”的技术让两个继承体系组合在一起使用。它将为原有继承体系增加虚接口的行为变成了为一个新的继承体系增加一个类型。Visitor以我们“不需要的优势”换取我们“需要的优势”，使用Visitor可以让我们方便地为原有继承体系增加新的虚函数，但同时也造成原有继承体系难以添加新的子类。
上例使用Visitor设计模式修改后，类的关系如下：
对应的代码如下：
struct AnimalVisitor
{
virtual void visit(Cat&) = 0;
virtual void visit(Dog&) = 0;
virtual ~AnimalVisitor(){}
};
struct RunVisitor : AnimalVisitor
{
private:
void visit(Cat& cat) override
{
// implement how cat run here;
}
void visit(Dog& dog) override
{
// implement how dog run here;
}
};
struct CryVisitor : AnimalVisitor
{
private:
void visit(Cat& cat) override
{
// implement how cat cry here;
}
void visit(Dog& dog) override
{
// implement how dog cry here;
}
};
struct Animal
{
virtual void accept(AnimalVisitor&) = 0;
virtual ~Animal(){}
};
struct Cat : Animal
{
private:
void accept(AnimalVisitor& visitor) override
{
visitor.visit(*this);
}
};
struct Dog : Animal
{
private:
void accept(AnimalVisitor& visitor) override
{
visitor.visit(*this);
}
};
可以看到，使用了Visitor设计模式后，每当为Animal继承体系增加一个新的虚函数，只用在AnimalVisitor继承体系中增加一个新的子类即可。但如果要为Animal增加子类，那么AnimalVisitor继承体系中的所有类就都得变化。如前面所说，我们假设Animal的继承体系是稳定的，所以我们才借助Visitor设计模式帮我们以“不需要的优势”换取了我们“需要的优势”，从而让代码面对假设的变化趋势保持了开放封闭性。
在Visitor设计模式中我们使用了“双向派发”技术。首先Animal体系中的类接收一个具体Visitor的时候，都是将其转化为父类引用去调用accept，然后再将自身传递给Visitor类的visit接口，此时visit又是通过重载函数的参数类型来区分调用的具体接口。所以即使Cat和Dog中的accept的实现看似一样，但却不能将其提到父类中去。
对Animal的使用如下：
RunVisitor run;
CryVisitor cry;
Animal* animals[] = {new Dog, new Cat};
animals[0]->accept(run); // dog run
animals[1]->accept(cry); // cat cry
for(auto animal : animals) delete animal;
对Visitor设计模式的使用就介绍到这里，我们来看看Visitor设计模式自身。它的架构是确定的，首先需要有一个继承体系(如Animal继承体系)，我们称为被访问体系。Visitor设计模式需要针对被访问体系创建一个访问者体系。访问者体系需要一个接口类(如 AnimalVisitor)，它的所有虚函数模式一致，即针对被访问体系中的每个类型创建visit函数，入参是被访问体系中类型的引用。被访问体系中每个类都有一个相同实现的accept接口。
可以看到Visitor设计模式具有确定的架构模式，我们能否利用模板元编程来做代码生成，让客户尽量只用实现确定模式之外的定制代码呢？
《Modern C++ Design》一书中，Andrei Alexandrescu利用TypeList完成了这件事，在此我们来看看他是如何做到的！为了让代码更加的清晰，我对原书的例子和代码进行了改进，所以注意下面所示代码和原书有所出入。
首先：由于被访问体系是已经存在的，所以我们可以让访问者体系根据被访者体系中的类型自动生成其接口类。
template<typename T>
struct Visitor
{
virtual void doVisit(T&) = 0;
virtual ~Visitor() {}
};
template<typename TL>
struct VisitorGenerator : __scatter_inherits(TL, Visitor)
{
template<typename Visited>
void visit(Visited& host)
{
return static_cast<Visitor<Visited>*>(this)->doVisit(host);
}
};
这里我们使用了前面介绍过的__scatter_inherits，它接收一个TypeList和一个单参模板Visitor，返回一个多重继承Visitor<T>(T为TypeList中每个元素)后的目标类型VisitorGenerator。我们通过代码生成，让VisitorGenerator中自动有了一系列virutal void doVisit(T&)的接口。最后VisitorGenerator自身定义了一个visit模板函数，通过入参类型将操作分派给对应父类的doVisit函数。
有了VisitorGenerator后，访问者继承体系的接口类后续如下定义：
using AnimalVisitor = VisitorGenerator<__type_list(Cat, Dog)>;
子类的实现和以前一样，仍然继承AnimalVisitor，只是虚接口的名称需要变为doVisit。例如：
struct RunVisitor : AnimalVisitor
{
private:
void doVisit(Cat& cat) override
{
// implement how cat run here;
}
void doVisit(Dog& dog) override
{
// implement how dog run here;
}
};
最后，为了消除被访问者体系中的重复accept函数代码，我们定义一个宏：
#define DEFINE_VISITABLE(VISITOR) \
void accept(VISITOR& visitor) override \
{ \
visitor.visit(*this); \
}
这样Animal继承体系中每个子类的实现可以简化如下：
struct Cat : Animal
{
private:
DEFINE_VISITABLE(AnimalVisitor);
};
struct Dog : Animal
{
private:
DEFINE_VISITABLE(AnimalVisitor);
};
OK，本例到此！我们通过代码生成消除了Visitor模式中的形式化代码，让客户可以生成Visitor模式的主框架，尽量只去编写需要自定义的代码。
上面的例子为了简化，假设访问者体系中的visit函数返回void类型。思考下如果我们希望visit接口的返回值类型能够指定，那么该如何修改代码？TLP库中"tlp/samples/visitor"目录中有完整的实现，可以参考。
