Visitor - 访问者模式

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

 

业务员此时典型的工作流程是：

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 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是耦合的。

评论

33 楼 yunhaifeiwu 2012-08-21  

补充：

public class Service { 
    public void accept(Visitor visitor) { 
        visitor.process(this);   
    } 
}  

这个也必须要变。

32 楼 yunhaifeiwu 2012-08-21  

men4661273 写道

几个service类是不是有问题呢，父类service有一个方法，三个子类集成父类，他们执行的还是父类的方法，这样的话，
s1.accept(visitor); 
        s2.accept(visitor); 
        s3.accept(visitor); 
三次执行的其实都是父类的
public void accept(Visitor visitor) { 
        visitor.process(this);   
    } 
然后每次执行的都是
public void process(Service service){ 
        // 默认业务 
    } 

================================
他作的并不全。

在使用中，visitor 仅仅是一个基类，使用中不会直接用它。visitor  相对于Service来说，它是让Service的功能保持不变，在他上面扩展。

补充全应是：

public class SavingVisitor extends Visitor{
     public void process(Saving service){  
        // 存款 扩展功能  
        //根据业务需,在某处会 执行service的存款业务处理
    }  
}

public class DrawVisitor extends Visitor{
     public void process(Draw service){  
        // 取款  扩展功能  
        //根据业务需,在某处会 执行service的 取款  业务处理
    }  
}

public class FundVisitor extends Visitor{
     public void process(Draw service){  
        // 查询  扩展功能  
        //根据业务需,在某处会 执行service的 查询 业务处理
    }  
}

使用，相应的也变成：

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

        DrawVisitor  dv= new DrawVisitor ();  
        s2.accept(dv);  
 
         FundVisitor  fv= new FundVisitor ();  
        s3.accept(fv);  
    }  
}  

31 楼 men4661273 2012-08-17  

几个service类是不是有问题呢，父类service有一个方法，三个子类集成父类，他们执行的还是父类的方法，这样的话，
s1.accept(visitor); 
        s2.accept(visitor); 
        s3.accept(visitor); 
三次执行的其实都是父类的
public void accept(Visitor visitor) { 
        visitor.process(this);   
    } 
然后每次执行的都是
public void process(Service service){ 
        // 默认业务 
    } 

30 楼 yunhaifeiwu 2008-12-08  

wangdi 写道

引用

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

其实，我非常想知道关于visitor模式的定义，，有了准确定义，实现应该会比较简单。
注：我这儿的accept()、process()方法和lz的对应的方法是不一样的。。

public interface IVisitor {
    public void accept(IService service);
}

public interface IService {
    public void process(IVisitor vistor);
}

public class Fund implements IService {
    public void process(IVisitor vistor){
        System.out.println("处理" + this);
    }
    
    public String toString(){
        return "基金业务";
    }
}

public class Saving implements IService {
    public void process(IVisitor vistor) {
        System.out.println("处理" + this);
    }

    public String toString() {
        return "存款业务";
    }
}

public class Visitor implements IVisitor {
    public void accept(IService service) {
        service.process(this);
    }
}

public class VisitorClients0 {
    public static void main(String[] args) {
        IVisitor visitor = new Visitor();
        
        IService fundService = new Fund();
        IService savingService = new Saving();
        
        visitor.accept(fundService);
        visitor.accept(savingService);
    }
}

网上关于访问者大多数定义都像楼主所举的。 但是访问者模式，重点是 不改变原有的类与类继承关系上，为原有的类体系增加新的功能

这是类图.由于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的AOP
      4 题化话------ 访问者名字的由来。也许是Element的各个子类---------为来访的客人预留下了座位。来访客人每次带一大包实用的礼物，让Element的子类的实例增加自已的魔法功能。来访的客人各不相同，带来的礼物五花八门，于是Element的子类的实例，展现出魔术般的神奇效果。

    
======================================================
以上是三年前对 vitor的个人理解。尘封了N久的记忆，总算被打开了。说事在的，二十三种模式，仅有少数几种留下了深刻的印像，其余的都淡忘掉了。唯独模式设计的封装变化点在心中。好在，还有自已能看懂的笔记一直保存着。

29 楼 yunhaifeiwu 2008-12-08  

哎！网上搜了一下，大部份都是这种答案。可惜啊，没把访问者的这一点所用上： 在不改变原有类与类的继承体系结构上，为原类继承体系增加新的方法。楼主恰恰只把访问者中的特例说到了（不增加新功能）。

28 楼 yunhaifeiwu 2008-12-08  

我再次狂晕，三年没看设计模式了。居然连策略模式都没印象了！

这里是教材网址:http://tech.ddvip.com/2008-11/122584658688974.html




这里出自李建忠的讲义:
==========================

引：在软件构建过程中，某些算法可能多种多样，经常改变，如果将 这些算法都编码在对象中，将会使得对象变得非常复杂，而且有时支持不使用的算法也是一个负担。
    意图：定义一系列算法，把它们一个个封装起来，并且使他们可以互相替换。该模式使得算法可以独立于使用它的客户而变化。
----------------------------------------

27 楼 yunhaifeiwu 2008-12-08  

http://tech.ddvip.com/2008-11/122584688388977.html

这是豆豆网上的观察者模式介绍。

楼主，所例举的，仅能辅助理解，并不全面。在重大考试中，会丢分。

建议楼主，在文中给出权威网站上的设计模式教材的网址。

26 楼 yunhaifeiwu 2008-12-08  

我狂晕！

这就是观察者模式？这就是访问者模式？

把访问者模式的局部取出来，就说是访问者模式。还有人说是观察者模式。



要详细学习设计模式，建议到网上下载李建忠的设计模式讲义或视频。这可是当年msdn、csdn 花钱请的。
国家软件设计师资格考试2005年的答案，在该讲师的讲义中能找到。



楼主所举的，仅仅是一种模式，并不是传说中的二十三模式之一。他仅仅是访问者模式的局部,或者说是访问者模式中的特例。难

http://tech.163.com/05/0718/10/1OUFF2JQ00091589.html这里有访问者模式的uml图

下面是观察者模式定义。来源于李建忠讲师的设计模式。
----------------------------------------------------
    在所软件构建过程中，需要为某些对象建立“一种依赖关系”—— 一个对象（目标对象）的状态发生改变，所有依赖对象（观察者对象）都将得到通知，如果这种关系过于紧密，将使软件不能很好的抵御变化。
    定义：定义对象间的一种“一对多的依赖关系”，以便当一个对象的状态发生改变时，有依赖它的对象都将得到通知并自动更新。

下面是访问者模式定义
========================
  引：类层次结构中，可能经常引入新的操作，从而将类型变得脆弱。在软件构建过程中，由于需求的变化，某些类层次结构中，经常需要添加新的方法，如果直接在基类更改，将会给子类带来严重的负担，甚至破坏原有设计。
    定义：表示一个作用于某对象结构中的各元素的操作。它可以在不改变各个元素类的前提下，定义于作用这些元素的新操作。

25 楼 kqy929 2008-12-07  

访问者模式主要是用于“调用多个算法，使用适用于不同的对象结构”。
但是该模式会使代码变得晦涩，出现循环访问的情况。
最近在看JSpider源码，其中，很多设计用来这个模式，谢谢楼主，学习了。
现更容易去仔细研究其源码。
刚开始时被JSpider中的该模式给扰得脑子一段乱 ，找不出真正实现者。感觉永远在自身调用自身。

24 楼 Nirvana 2008-10-07  

wangdi 写道

引用

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

有点没懂，，把service抽象成一个接口是否会比用继承好呢？而且不会有耦合。。。其实，我非常想知道关于visitor模式的定义，，有了准确定义，实现应该会比较简单。
注：我这儿的accept()、process()方法和lz的对应的方法是不一样的。。

public interface IVisitor {
    public void accept(IService service);
}

public interface IService {
    public void process(IVisitor vistor);
}

public class Fund implements IService {
    public void process(IVisitor vistor){
        System.out.println("处理" + this);
    }
    
    public String toString(){
        return "基金业务";
    }
}

public class Saving implements IService {
    public void process(IVisitor vistor) {
        System.out.println("处理" + this);
    }

    public String toString() {
        return "存款业务";
    }
}

public class Visitor implements IVisitor {
    public void accept(IService service) {
        service.process(this);
    }
}

public class VisitorClients0 {
    public static void main(String[] args) {
        IVisitor visitor = new Visitor();
        
        IService fundService = new Fund();
        IService savingService = new Saving();
        
        visitor.accept(fundService);
        visitor.accept(savingService);
    }
}

你的实现其实是策略模式，两者各有特点，各有长短

23 楼 wangdi 2008-10-04  

引用

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

有点没懂，，把service抽象成一个接口是否会比用继承好呢？而且不会有耦合。。。其实，我非常想知道关于visitor模式的定义，，有了准确定义，实现应该会比较简单。
注：我这儿的accept()、process()方法和lz的对应的方法是不一样的。。

public interface IVisitor {
    public void accept(IService service);
}

public interface IService {
    public void process(IVisitor vistor);
}

public class Fund implements IService {
    public void process(IVisitor vistor){
        System.out.println("处理" + this);
    }
    
    public String toString(){
        return "基金业务";
    }
}

public class Saving implements IService {
    public void process(IVisitor vistor) {
        System.out.println("处理" + this);
    }

    public String toString() {
        return "存款业务";
    }
}

public class Visitor implements IVisitor {
    public void accept(IService service) {
        service.process(this);
    }
}

public class VisitorClients0 {
    public static void main(String[] args) {
        IVisitor visitor = new Visitor();
        
        IService fundService = new Fund();
        IService savingService = new Saving();
        
        visitor.accept(fundService);
        visitor.accept(savingService);
    }
}

22 楼 xiaoqiang01 2008-10-04  

真的很感谢楼主...又学到了.

21 楼 风度少年 2008-09-20  

在Service的子类中必须重写accept()方法!呵呵~~~

20 楼 Ethan 2008-09-14  

这个模式并不是可以随便乱用的，看上去这个模式很简单，但是如果情况比较固定，如例子里面所说的三种业务情形的话，直接判断也未尝不可。Visitor模式适合于情况复杂，且随时准备扩展的情况下，比如说有十几种业务需要展开，而且时不时会推出新的业务，这时候就可以利用这个模式方便快捷的添加业务实现类了，而且不会影响到之前实现的业务逻辑。

19 楼 lkjust08 2008-09-09  

看了两次，这次才看明白是这要的呀
谢谢楼主了。

18 楼 h_yz 2008-09-04  

楼主大哥的这个vistor模式，小弟偶曾在工商银行取钱时就是这样的，呵呵，更加深了偶对visor的印象

17 楼 wjh0205 2008-09-04  

受教了，真的很不错。

16 楼 farryu 2008-09-02  

<div class='quote_title'>lintomny 写道</div>
<div class='quote_div'>
<p>话说有一个银行，有三个窗口，但是每个窗口的智能都是一样的，即都能办理所有的业务。因此每位来银行办理业务的人只要排队就是了，排到你了，就向业务员说明你要办理的业务，然后业务员根据你的业务选择不同的单据，打开不同的账本。……。</p>
<p> </p>
<p>业务员此时典型的工作流程是：</p>
<pre name='code' class='java'>if (service instanceof Saving){
    //存款
   ......
}else if (service instanceof Draw){
    //提款
   ......
}else if (service instanceof Fund){
    //基金
   ......
}
......</pre>
 
<p>于是每位业务员的桌面总是塞得满满的，更重要的是大量的时间都花在受理不同业务之间的切换，使得效率很低。</p>
<p> </p>
<p>有没有方法能够使得业务员的工作效率提高呢？银行经理苦思冥想了半天，终于想出了一个好办法。他让每个窗口各负责一个业务，同时委任了一位访问者(Visitor)，负责在客户进门时，询问他要办理什么业务，告诉他应该去哪个窗口办理。这样，每个窗口的业务员就只负责一项业务，<span style='color: #ff0000;'><strong>减少了在不同业务间切换的时间耗费</strong>
</span>
，效率大大提高。更重要的是，<span style='color: #ff0000;'><strong>当某一项业务的处理流程发生变更时，不需要同时麻烦三个窗口的业务员，而只需要让处理这项业务的业务员进行修改就可以了</strong>
</span>
。</p>
<p> </p>
<p>下面就来定义Visitor类，这个Visitor类实际上还办含了不同窗口受理员的职责，可以认为是银行的受理反应机制吧。</p>
<p> </p>
<pre name='code' class='java'>public class Visitor {

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

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

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

public void process(Fund service){
// 基金
}
} </pre>
 
<p>接着我们定义业务基类。</p>
<p> </p>
<pre name='code' class='java'>public class Service {
public void accept(Visitor visitor) {
visitor.process(this);
}
} </pre>
<p> </p>
<p>不同的业务类。</p>
<pre name='code' class='java'>public class Saving extends Service {
//各种业务处理流程
}</pre>
 
<pre name='code' class='java'>public class Draw extends Service {
//各种业务处理流程
}</pre>
 
<pre name='code' class='java'>public class fund extends Service {
//各种业务处理流程
}</pre>
 
<p>好了，接下来就是我们的访问者与到来的客户之间的交互了。</p>
<pre name='code' class='java'>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);
}
}</pre>
 
<p>后话：专门设定一个访问者的职位还是有点多余，于是后来银行经理请设备公司做了一个排号机来代替访问者。</p>
<p> </p>
<p><strong><span style='font-size: medium;'>总结</span>
</strong>
</p>
<p>Visitor模式实际上是利用的语言本身的特性，见Vistor类的各个函数，通过不同的参数来自动查找相应的处理函数。</p>
<p> </p>
<p>采用Visitor的好处如上面说到的那样，当需要改变其中一项业务的处理时，不需要每个地方都进行修改，而只需要改动Visitor类中相应的处理函数就可以了。也就是说它适合于业务处理时常发生变动的情况。</p>
<p> </p>
<p>当然，Visitor也有它自身的限制。它不适合于业务数量的经常变化，因为一旦新增或删除一些Service时，需要对visitor进行相应的增删。也就是说具体Service与Visitor是耦合的。</p>
<p> </p>
</div>
<p>观察者模式写的深刻，不过觉得和mvc模式的功能类似，有可能的话用这个要好些</p>

15 楼 zhangcheng 2008-09-02  

解释的不错，不过可能稍有点不够详细。

14 楼 rainerWJY 2008-09-02  

plpq 写道

aninfeel 写道

说白了就是把service的逻辑放到visitor里了

那他到底有什么好处呢

http://www.iteye.com/topic/235585
他那个需求在某些情况下就可以转换为visitor.
不过本身visitor不是必须的一个需要
当你觉得做一个事情特别麻烦的时候，考虑用模式优化下。。