23种设计模式：访问者模式

深入浅出Java的访问者模式

blog2005-07-16 12:41


分享到：我要吐槽

　　一、引子

　　对于系统中一个已经完成的类层次结构，我们已经给它提供了满足需求的接口。但是面对新增加的需求，我们应该怎么做呢？如果这是为数不多的几次变动，而且你不用为了一个需求的调整而将整个类层次结构统统地修改一遍，那么直接在原有类层次结构上修改也许是个不错的主意。

　　但是往往我们遇到的却是：这样的需求变动也许会不停的发生；更重要的是需求的任何变动可能都要让你将整个类层次结构修改个底朝天……。这种类似的操作分布在不同的类里面，不是一个好现象，我们要对这个结构重构一下了。

　　那么，访问者模式也许是你很好的选择。

　　二、定义与结构

　　访问者模式，顾名思义使用了这个模式后就可以在不修改已有程序结构的前提下，通过添加额外的“访问者”来完成对已有代码功能的提升。

　　《设计模式》一书对于访问者模式给出的定义为：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。从定义可以看出结构对象是使用访问者模式必须条件，而且这个结构对象必须存在遍历自身各个对象的方法。这便类似于java中的collection概念了。

　　以下是访问者模式的组成结构：

　　1) 访问者角色（Visitor）：为该对象结构中具体元素角色声明一个访问操作接口。该操作接口的名字和参数标识了发送访问请求给具体访问者的具体元素角色。这样访问者就可以通过该元素角色的特定接口直接访问它。

　　2) 具体访问者角色（Concrete Visitor）：实现每个由访问者角色（Visitor）声明的操作。

　　3) 元素角色（Element）：定义一个Accept操作，它以一个访问者为参数。

　　4) 具体元素角色（Concrete Element）：实现由元素角色提供的Accept操作。

　　5) 对象结构角色（Object Structure）：这是使用访问者模式必备的角色。它要具备以下特征：能枚举它的元素；可以提供一个高层的接口以允许该访问者访问它的元素；可以是一个复合（组合模式）或是一个集合，如一个列表或一个无序集合。

　　来张类图就能更加清晰的看清访问者模式的结构了。

　　那么像引言中假想的。我们应该做些什么才能让访问者模式跑起来呢？首先我们要在原有的类层次结构中添加accept方法。然后将这个类层次中的类放到一个对象结构中去。这样再去创建访问者角色……

　　三、举例

　　本人阅历实在可怜，没能找到访问者模式在实际应用中的例子。只好借《Thinking in Patterns with java》中的教学代码一用。我稍微做了下修改。

import java.util.*; import junit.framework.*; //访问者角色 interface Visitor { 　void visit(Gladiolus g); 　void visit(Runuculus r); 　void visit(Chrysanthemum c); } // The Flower hierarchy cannot be changed: //元素角色 interface Flower { 　void accept(Visitor v); } //以下三个具体元素角色 class Gladiolus implements Flower { 　public void accept(Visitor v) { v.visit(this);} } class Runuculus implements Flower { 　public void accept(Visitor v) { v.visit(this);} } class Chrysanthemum implements Flower { 　public void accept(Visitor v) { v.visit(this);} } // Add the ability to produce a string: //实现的具体访问者角色 class StringVal implements Visitor { 　String s; 　public String toString() { return s; } 　public void visit(Gladiolus g) { 　　s = "Gladiolus"; 　} 　public void visit(Runuculus r) { 　　s = "Runuculus"; 　} 　public void visit(Chrysanthemum c) { 　　s = "Chrysanthemum"; 　} } // Add the ability to do "Bee" activities: //另一个具体访问者角色 class Bee implements Visitor { 　public void visit(Gladiolus g) { 　　System.out.println("Bee and Gladiolus"); 　} 　public void visit(Runuculus r) { 　　System.out.println("Bee and Runuculus"); 　} 　public void visit(Chrysanthemum c) { 　　System.out.println("Bee and Chrysanthemum"); 　} } //这是一个对象生成器 //这不是一个完整的对象结构，这里仅仅是模拟对象结构中的元素 class FlowerGenerator { 　private static Random rand = new Random(); 　public static Flower newFlower() { 　　switch(rand.nextInt(3)) { 　　default: 　　　case 0: return new Gladiolus();　 　　　case 1: return new Runuculus(); 　　　case 2: return new Chrysanthemum(); 　　} 　} } //客户测试程序 public class BeeAndFlowers extends TestCase { 　/* 　　在这里你能看到访问者模式执行的流程： 　　首先在客户端先获得一个具体的访问者角色 　　遍历对象结构 　　对每一个元素调用accept方法，将具体访问者角色传入 　　这样就完成了整个过程 　*/ 　//对象结构角色在这里才组装上 　List flowers = new ArrayList(); 　public BeeAndFlowers() { 　　for(int i = 0; i < 10; i++) 　　　flowers.add(FlowerGenerator.newFlower()); 　} 　Visitor sval ; 　public void test() { 　　// It’s almost as if I had a function to 　　// produce a Flower string representation: 　　//这个地方你可以修改以便使用另外一个具体访问者角色 　　sval = new StringVal(); 　　Iterator it = flowers.iterator(); 　　while(it.hasNext()) { 　　　((Flower)it.next()).accept(sval); 　　　System.out.println(sval); 　　} 　} 　public static void main(String args[]) { 　　junit.textui.TestRunner.run(BeeAndFlowers.class); 　} }

　　四、双重分派

　　对了，你在上面的例子中体会到双重分派的实现了没有？

　　首先在客户程序中将具体访问者模式作为参数传递给具体元素角色（加亮的地方所示）。这便完成了一次分派。

　　进入具体元素角色后，具体元素角色调用作为参数的具体访问者模式中的visitor方法，同时将自己（this）作为参数传递进去。具体访问者模式再根据参数的不同来选择方法来执行（加亮的地方所示）。这便完成了第二次分派。

　　五、优缺点及适用情况

　　先来看下访问者模式的使用能否避免引言中的痛苦。使用了访问者模式以后，对于原来的类层次增加新的操作，仅仅需要实现一个具体访问者角色就可以了，而不必修改整个类层次。而且这样符合“开闭原则”的要求。而且每个具体的访问者角色都对应于一个相关操作，因此如果一个操作的需求有变，那么仅仅修改一个具体访问者角色，而不用改动整个类层次。

　　看来访问者模式确实能够解决我们面临的一些问题。

　　而且由于访问者模式为我们的系统多提供了一层“访问者”，因此我们可以在访问者中添加一些对元素角色的额外操作。

　　但是“开闭原则”的遵循总是片面的。如果系统中的类层次发生了变化，会对访问者模式产生什么样的影响呢？你必须修改访问者角色和每一个具体访问者角色……

　　看来访问者角色不适合具体元素角色经常发生变化的情况。而且访问者角色要执行与元素角色相关的操作，就必须让元素角色将自己内部属性暴露出来，而在java中就意味着其它的对象也可以访问。这就破坏了元素角色的封装性。而且在访问者模式中，元素与访问者之间能够传递的信息有限，这往往也会限制访问者模式的使用。

　　《设计模式》一书中给出了访问者模式适用的情况：

　　1) 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。

　　2) 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Visitor使得你可以将相关的操作集中起来定义在一个类中。

　　3) 当该对象结构被很多应用共享时，用Visitor模式让每个应用仅包含需要用到的操作。

　　4) 定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。

　　你是否能很好的理解呢？

　　六、总结

　　这是一个巧妙而且复杂的模式，它的使用条件比较苛刻。当系统中存在着固定的数据结构（比如上面的类层次），而有着不同的行为，那么访问者模式也许是个不错的选择。

==========================================================================

定义：封装某些作用于某种数据结构中各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

类型：行为类模式

类图：





访问者模式可能是行为类模式中最复杂的一种模式了，但是这不能成为我们不去掌握它的理由。我们首先来看一个简单的例子，代码如下：

[java] view
plain copy

class A {

public void method1(){

System.out.println("我是A");

}



public void method2(B b){

b.showA(this);

}

}



class B {

public void showA(A a){

a.method1();

}

}

我们主要来看一下在类A中，方法method1和方法method2的区别在哪里，方法method1很简单，就是打印出一句“我是A”；方法method2稍微复杂一点，使用类B作为参数，并调用类B的showA方法。再来看一下类B的showA方法，showA方法使用类A作为参数，然后调用类A的method1方法，可以看到，method2方法绕来绕去，无非就是调用了一下自己的method1方法而已，它的运行结果应该也是“我是A”，分析完之后，我们来运行一下这两个方法，并看一下运行结果：

[java] view
plain copy

public class Test {

public static void main(String[] args){

A a = new A();

a.method1();

a.method2(new B());

}

}

运行结果为：

我是A

我是A

看懂了这个例子，就理解了访问者模式的90%，在例子中，对于类A来说，类B就是一个访问者。但是这个例子并不是访问者模式的全部，虽然直观，但是它的可扩展性比较差，下面我们就来说一下访问者模式的通用实现，通过类图可以看到，在访问者模式中，主要包括下面几个角色：

抽象访问者：抽象类或者接口，声明访问者可以访问哪些元素，具体到程序中就是visit方法中的参数定义哪些对象是可以被访问的。
访问者：实现抽象访问者所声明的方法，它影响到访问者访问到一个类后该干什么，要做什么事情。
抽象元素类：接口或者抽象类，声明接受哪一类访问者访问，程序上是通过accept方法中的参数来定义的。抽象元素一般有两类方法，一部分是本身的业务逻辑，另外就是允许接收哪类访问者来访问。
元素类：实现抽象元素类所声明的accept方法，通常都是visitor.visit(this)，基本上已经形成一种定式了。
结构对象：一个元素的容器，一般包含一个容纳多个不同类、不同接口的容器，如List、Set、Map等，在项目中一般很少抽象出这个角色。

访问者模式的通用代码实现

[java] view
plain copy

abstract class Element {

public abstract void accept(IVisitor visitor);

public abstract void doSomething();

}



interface IVisitor {

public void visit(ConcreteElement1 el1);

public void visit(ConcreteElement2 el2);

}



class ConcreteElement1 extends Element {

public void doSomething(){

System.out.println("这是元素1");

}



public void accept(IVisitor visitor) {

visitor.visit(this);

}

}



class ConcreteElement2 extends Element {

public void doSomething(){

System.out.println("这是元素2");

}



public void accept(IVisitor visitor) {

visitor.visit(this);

}

}

class Visitor implements IVisitor {



public void visit(ConcreteElement1 el1) {

el1.doSomething();

}



public void visit(ConcreteElement2 el2) {

el2.doSomething();

}

}



class ObjectStruture {

public static List<Element> getList(){

List<Element> list = new ArrayList<Element>();

Random ran = new Random();

for(int i=0; i<10; i++){

int a = ran.nextInt(100);

if(a>50){

list.add(new ConcreteElement1());

}else{

list.add(new ConcreteElement2());

}

}

return list;

}

}



public class Client {

public static void main(String[] args){

List<Element> list = ObjectStruture.getList();

for(Element e: list){

e.accept(new Visitor());

}

}

}

访问者模式的优点

符合单一职责原则：凡是适用访问者模式的场景中，元素类中需要封装在访问者中的操作必定是与元素类本身关系不大且是易变的操作，使用访问者模式一方面符合单一职责原则，另一方面，因为被封装的操作通常来说都是易变的，所以当发生变化时，就可以在不改变元素类本身的前提下，实现对变化部分的扩展。
扩展性良好：元素类可以通过接受不同的访问者来实现对不同操作的扩展。

访问者模式的适用场景

假如一个对象中存在着一些与本对象不相干（或者关系较弱）的操作，为了避免这些操作污染这个对象，则可以使用访问者模式来把这些操作封装到访问者中去。

假如一组对象中，存在着相似的操作，为了避免出现大量重复的代码，也可以将这些重复的操作封装到访问者中去。

但是，访问者模式并不是那么完美，它也有着致命的缺陷：增加新的元素类比较困难。通过访问者模式的代码可以看到，在访问者类中，每一个元素类都有它对应的处理方法，也就是说，每增加一个元素类都需要修改访问者类（也包括访问者类的子类或者实现类），修改起来相当麻烦。也就是说，在元素类数目不确定的情况下，应该慎用访问者模式。所以，访问者模式比较适用于对已有功能的重构，比如说，一个项目的基本功能已经确定下来，元素类的数据已经基本确定下来不会变了，会变的只是这些元素内的相关操作，这时候，我们可以使用访问者模式对原有的代码进行重构一遍，这样一来，就可以在不修改各个元素类的情况下，对原有功能进行修改。



总结

正如《设计模式》的作者GoF对访问者模式的描述：大多数情况下，你并需要使用访问者模式，但是当你一旦需要使用它时，那你就是真的需要它了。当然这只是针对真正的大牛而言。在现实情况下（至少是我所处的环境当中），很多人往往沉迷于设计模式，他们使用一种设计模式时，从来不去认真考虑所使用的模式是否适合这种场景，而往往只是想展示一下自己对面向对象设计的驾驭能力。编程时有这种心理，往往会发生滥用设计模式的情况。所以，在学习设计模式时，一定要理解模式的适用性。必须做到使用一种模式是因为了解它的优点，不使用一种模式是因为了解它的弊端；而不是使用一种模式是因为不了解它的弊端，不使用一种模式是因为不了解它的优点。