访问者模式

话说有一个银行，有三个窗口，但是每个窗口的智能都是一样的，即都能办理所有的业务。因此每位来银行办理业务的人只要排队就是了，排到你了，就向业务员说明你要办理的业务，然后业务员根据你的业务选择不同的单据，打开不同的账本。……。

业务员此时典型的工作流程是：
if (service instanceof Saving){
    //存款
   ......
}else if (service instanceof Draw){
    //提款
   ......
}else if (service instanceof Fund){
    //基金
   ......
}
......

于是每位业务员的桌面总是塞得满满的，更重要的是大量的时间都花在受理不同业务之间的切换，使得效率很低。

有没有方法能够使得业务员的工作效率提高呢？银行经理苦思冥想了半天，终于想出了一个好办法。他让每个窗口各负责一个业务，同时委任了一位访问者 (Visitor)，负责在客户进门时，询问他要办理什么业务，告诉他应该去哪个窗口办理。这样，每个窗口的业务员就只负责一项业务，减少了在不同业务间切换的时间耗费 ，效率大大提高。更重要的是，当某一项业务的处理流程发生变更时，不需要同时麻烦三个窗口的业务员，而只需要让处理这项业务的业务员进行修改就可以了 。

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

public void process(Service service){
// 默认业务
}

public void process(Saving service){
// 存款
}

public void process(Draw service){
// 提款
}

public void process(Fund service){
// 基金
}
}

接着我们定义业务基类。

public class Service {
public void accept(Visitor visitor) {
visitor.process(this);
}
}
不同的业务类。
public class Saving extends Service {
//各种业务处理流程
}
public class Draw extends Service {
//各种业务处理流程
}
public class Draw extends Service {
//各种业务处理流程
}
public class fund extends Service {
//各种业务处理流程
}

好了，接下来就是我们的访问者与到来的客户之间的交互了。

public class Client {
public static void main(String[] args) {
Service s1 = new Saving();
Service s2 = new Draw();
Service s3 = new Fund();

Visitor visitor = new Visitor();

s1.accept(visitor);
s2.accept(visitor);
s3.accept(visitor);
}
}

后话：专门设定一个访问者的职位还是有点多余，于是后来银行经理请设备公司做了一个排号机来代替访问者。

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

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

当然，Visitor也有它自身的限制。它不适合于业务数量的经常变化，因为一旦新增或删除一些Service时，需要对visitor进行相应的增删。也就是说具体Service与Visitor是耦合的。

访问者的进阶篇：
http://www.iteye.com/topic/345384