《设计模式之禅》之访问者模式

一、访问者模式的定义

访问者模式是一个相对简单的模式，其定义如下:
封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

角色职责

Visitor–抽象访问者

抽象类或者接口，声明访问者可以访问哪些元素，具体到程序中就是visit方法的参数定义哪些对象是可以被访问的。

ConcreteVisitor–具体访问者

它影响访问者访问到一个类中该怎么干，要做什么事情。

Element–抽象元素

接口或者抽象类，声明接受哪一类访问者访问，程序上是通过accept方法中的参数来定义的。

ConcreteElement–具体元素

实现accept方法，通常是visitor.visit(this)，基本上都形成了一种模式。

ObjectStruture–结构对象

元素产生者，一般容纳在多个不同类、不同接口的容器，如List、Set、Map等，在项目中，一般很少抽象出这个角色。

换言之，大家可以这样理解访问者模式:
我作为一个访客(Visitor)到朋友家(Visited Class)去拜访，朋友之间聊聊天、喝喝酒，再相互吹捧吹捧，炫耀炫耀，这都正常。聊天的时候，朋友告诉我，他今年加官晋爵了，工资也涨了30%，准备再买套房子，那我就在心里盘算(Visitor-self-method)，你这么有钱，我去年要借10万你都不借，我根据朋友的信息，执行了自己一个方法。

二、访问者模式的应用

1.访问者模式的优点

(1)符合单一职责原则

具体元素角色也就是Employee抽象类的两个子类负责数据的加载，而Visitor类则负责报表的展现，两个不同的职责非常明确地分离开来，各自演绎变化。

(2)优秀的扩展性

由于职责分开，继续增加对数据的操作是非常快捷的，例如，现在要增加一份给大老板的报表这份报表格式又有所不同，直接在Visitor中增加一个方法，传递数据后进行整理打印。

(3)灵活性非常高

例如，数据汇总。

2.访问者模式的缺点

(1)具体元素对访问者公布细节

访问者要访问一个类就必然要求这个类公布一些方法和数据，也就是访问者关注了其他类的内部细节，这就是迪米特法则所不建议的。

(2)具体元素变更比较困难

具体元素角色的增加、删除、修改都是比较困难的，就上面那个例子，你想想，你要是想增加一个成员变量，如年龄age，Visitor就需要修改，如果Visitor是一个还好办，多个呢？业务逻辑再复杂点呢？

(3)违背了依赖倒置原则

访问者依赖的是具体元素，而不是抽象元素，这破坏了依赖倒置原则，特别是面向对象的编程中，抛弃了对接口的依赖，而直接依赖实现类，扩展比较难。

3.访问者模式的使用场景

• 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作，也就说是用迭代器模式已经不能胜任的场景。
• 需要对一个对象结构中的对象进行很多不同并且不相关的操作，而你想避免让这些操作”污染”这些对象的类。

四、访问者模式的扩展

1.统计功能(汇总和报表)

2.多个访问者

3.双分派

五、最佳实践

访问者模式是一种集中规整模式，特别适用于大规模重构的项目，在这一个阶段需求已经非常清晰，原系统的功能点也已经明确，通过访问者模式可以很容易把一些功能进行梳理，达到最终目的–功能集中化，如一个统一的报表运算、UI展现等，我们还可以与其他模式混编建立一套自己的过滤器或者拦截器。
代码例子:
https://github.com/developers-youcong/DesignPatternPractice/tree/master/Visitor