Visitor - 访问者模式

Visitor - 访问者模式话说有一个银行，有三个窗口，但是每个窗口的智能都是一样的，即都能办理所有的业务。

因此每位来银行办理业务的人只要排队就是了，排到你了，就向业务员说明你要办理的业务，然后业务员根据你的业务选择不同的单据，打开不同的账本。

……。

业务员此时典型的工作流程是：Java代码1if (service instanceof Saving){2//存款3 ......4}else if (service instanceof Draw){5//提款6 ......7}else if (service instanceof Fund){8//基金9 ......10}11......于是每位业务员的桌面总是塞得满满的，更重要的是大量的时间都花在受理不同业务之间的切换，使得效率很低。

有没有方法能够使得业务员的工作效率提高呢？银行经理苦思冥想了半天，终于想出了一个好办法。

他让每个窗口各负责一个业务，同时委任了一位访问者(Visitor)，负责在客户进门时，询问他要办理什么业务，告诉他应该去哪个窗口办理。

这样，每个窗口的业务员就只负责一项业务，减少了在不同业务间切换的时间耗费，效率大大提高。

更重要的是，当某一项业务的处理流程发生变更时，不需要同时麻烦三个窗口的业务员，而只需要让处理这项业务的业务员进行修改就可以了。

下面就来定义Visitor类，这个Visitor类实际上还办含了不同窗口受理员的职责，可以认为是银行的受理反应机制吧。

Java代码12public class Visitor {1314public void process(Service service){ 15// 默认业务16}1718public void process(Saving service){ 19// 存款20}2122public void process(Draw service){23// 提款24}2526public void process(Fund service){27// 基金28}29}接着我们定义业务基类。

Java代码30public class Service {31public void accept(Visitor visitor) {32visitor.process(this);33}34}不同的业务类。

Java代码35public class Saving extends Service {36//各种业务处理流程37}Java代码38public class Draw extends Service {39//各种业务处理流程40}Java代码41public class fund extends Service {42//各种业务处理流程43}好了，接下来就是我们的访问者与到来的客户之间的交互了。

Java代码44public class Client {45public static void main(String[] args) {46Service s1 = new Saving();47Service s2 = new Draw();48Service s3 = new Fund();4950Visitor visitor = new Visitor();5152s1.accept(visitor);53s2.accept(visitor);54s3.accept(visitor);55}56}后话：专门设定一个访问者的职位还是有点多余，于是后来银行经理请设备公司做了一个排号机来代替访问者。

总结Visitor模式实际上是利用的语言本身的特性，见Vistor类的各个函数，通过不同的参数来自动查找相应的处理函数。

采用Visitor的好处如上面说到的那样，当需要改变其中一项业务的处理时，不需要每个地方都进行修改，而只需要改动Visitor类中相应的处理函数就可以了。

也就是说它适合于业务处理时常发生变动的情况。

当然，Visitor也有它自身的限制。

它不适合于业务数量的经常变化，因为一旦新增或删除一些Service时，需要对visitor进行相应的增删。

也就是说具体Service与Visitor是耦合的。

wangdi 写道引用当然，Visitor也有它自身的限制。

它不适合于业务数量的经常变化，因为一旦新增或删除一些Service时，需要对visitor进行相应的增删。

也就是说具体Service与Visitor是耦合的。

其实，我非常想知道关于visitor模式的定义，，有了准确定义，实现应该会比较简单。

注：我这儿的accept()、process()方法和lz的对应的方法是不一样的。

Java代码1public interface IVisitor {2public void accept(IService service);3}Java代码4public interface IService {5public void process(IVisitor vistor);6}Java代码7public class Fund implements IService {8public void process(IVisitor vistor){9System.out.println("处理" + this);10}1112public String toString(){13return"基金业务";14}15}Java代码16public class Saving implements IService {17public void process(IVisitor vistor) {18System.out.println("处理" + this);19}2021public String toString() {22return"存款业务";23}24}Java代码25public class Visitor implements IVisitor {26public void accept(IService service) {27service.process(this);28}29}Java代码30public class VisitorClients0 {31public static void main(String[] args) {32IVisitor visitor = new Visitor();3334IService fundService = new Fund();35IService savingService = new Saving();3637visitor.accept(fundService);38visitor.accept(savingService);39}40}网上关于访问者大多数定义都像楼主所举的。

但是访问者模式，重点是不改变原有的类与类继承关系上，为原有的类体系增加新的功能这是类图.由于163的也是一个减化图，因此自已重新传一张，进行说明上图中ObjectStructure所指示的类结构，是固定的，是不希望发生变化的。

但是，这个类的各个子类，他们要经常增加新的功能或操作。

如何不改变这个类结构，又能在原有的基础上增加新的操作呢？则这些子类ConcreateElenmentA、ConcreateElenmentB 预先调用一个功能扩展方法（即accept).如果没有功能变化，这个对象就是null,或有他是其方法中的是一个空语句。

而这个功能扩展方法，有一个参数-------Vistor对象，这个对象装载着新功能变化。

Vistor类的方法，对应着Element中各个子类，使用了accept方法的方法，如果当Element 中的某个子类如ConcreateElenmentA，要增加功能了，则把新功能写在Vistor子类中.具体作法是，单写一个类，让它继承Vistor，由于这里是增加ConcreateElenmentA的功能，则在自已写的这个类中覆盖VistorConcreateElenmenA方法就行了。

然后把自已写的类，生成一个实例，传递给ConcreateElenmentA对象.简单说：1 Element 类继承体系中，其继承关系不变，各个子类不变。

但是，各个子类的却经常需要增加新功能。

-----------这是我们的想要达到的目的。

2 实现方法：先定义一套方法封装在vistor类中。

这套方法中，每个方法对应着一个Element子类。

Element子类则在事先在代码中，谳用这个vistor对象中与自已相对应的方法。

而accept方法，就是传输管道。

当用户要增加Element的子类ConcreateElenmentA时，具体使用如下：（1）写一个Vistor1继承Vistor。

Vistor1中，覆盖VistorConcreateElenmenA方法，写新加入的功能。

（2）生成Vistor1的实例。

其名取为vistor1（3）生成ConcreateElenmentA的实例，取名concreateElenmentA（4）定义一个Element变量，名为e，其值为vistor1 ; 定义一个Vistor变量，名为v，其值为concreateElenmentA（5）用如下语句增加ConcreateElenmentA的实例的功能。

e.accpt(v)（6）当ConcreateElenmentA的实例的功能又变化了，则修改第一条与第四条。

重写一个Vistor的子类，并赋值给变量v即可。

其他代码根本不用改变了。

出色的达到了我们想要的目的.3 这个场景可用spring的AOP4 题化话------ 访问者名字的由来。

也许是Element的各个子类---------为来访的客人预留下了座位。

来访客人每次带一大包实用的礼物，让Element的子类的实例增加自已的魔法功能。

来访的客人各不相同，带来的礼物五花八门，于是Element的子类的实例，展现出魔术般的神奇效果。

======================================================以上是三年前对vitor的个人理解。

尘封了N久的记忆，总算被打开了。

说事在的，二十三种模式，仅有少数几种留下了深刻的印像，其余的都淡忘掉了。

唯独模式设计的封装变化点在心中。

好在，还有自已能看懂的笔记一直保存着。

Visitor模式的使用情景以及与Iterator的比较见我以前的一篇文章/blog/166142这次主要讨论Visitor的两种实现方式及其优劣。