结构
面向对象中封装的想法是将数据和操作数据的方法集中在一个类中，以达到高内聚低耦合的效果。但是有时也会希望将目的相关或相同的针对不同类型的操作集中到一个类中。这种方式就是访问者模式，它的结构如下：
上图引用自《设计模式》一书
访问者类Visitor定义两个不同的接口分别用于访问构造图下半部分的两个Element的派生类。访问者类Visitor通过不同的方法决定它的派生类可以访问的对象类型。
具象访问者类ConcreteVisitor类负责具体实现一组针对访问者类指定的对象的具体操作。每个访问方法往往是某个更大算法的一部分，所以经常会需要使用具象访问者类的数据成员来保存这个算法的信息。由于需求的不同，并不要求每个具象类都必须实现所有的访问方法。
元素类Element作为要素类的基类，首先应该有自己的功能，然后才是为继承层次上的具象要素类定义用来接纳访问者类的accpet方法。也可以定义一个只有accept方法的抽象类，但是个人觉得这多少有些本末倒置的感觉。要素类的类结构还是应该按照其本身的需求进行设计，而不是为了访问者模式这么一个实现层面的便利而改变。
具象要素类ConcreteElement作为访问者的访问对象，负责招待访问者。在它的accept方法中会调用Visitor的对应方法。这个过程可以看作是将具象Visitor类和访问对象放到一起之后，访问对象和Visitor的访问方法之间实现自动匹配。这也可以认为是一种重载，是访问者模式最为神奇的地方。
对象结构ObjectStructure只是一个提法，并不存在这么个类。之所以需要这个角色，个人觉得可以这样理解：对某个数据结构进行的处理总可以看作是数据结构遍历和处理数据的结合。Visitor类只负责处理，那么就需要某个角色来推进遍历动作，而这个角色就是ObjectStructrue。由于在整个遍历、处理的过程中Visitor始终处于被动地位，因此也就不在乎ObjectStructure具体是什么结构了。而这个不在乎正是面向对象中的解耦合。
觉得本文有帮助？请分享给更多人。
关注【面向对象思考】，轻松学习每一天！
向对象设计，面向对象编程，面向对象思考！
閱讀更多 面向對象思考 的文章
