标签：之禅 对象 Visitor 元素 模式 具体 设计模式 访问者

一、访问者模式的定义

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

角色职责

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

标签：之禅,对象,Visitor,元素,模式,具体,设计模式,访问者
来源： https://www.cnblogs.com/youcong/p/12631050.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。