19.访问者模式(Visitor Pattern)

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

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

    if (service instanceof Saving){  
        //存款  
       ......  
    }else if (service instanceof Draw){  
        //提款  
       ......  
    }else if (service instanceof Fund){  
        //基金  
       ......  
    }   
    ......  

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

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

1.定义

封装一些作用于某种数据结构中的各元素的操作,它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
访问者的实现依赖了Java的重载机制。

 

2.访问者模式的五个角色

  • Visitor-抽象访问者:抽象类或者接口,声明访问者可以访问哪些元素,具体到程序中就是visit方法的参数定义哪些对象是可以被访问的。
  • ConcreteVisitor-具体访问者:它影响访问者访问到一个类后该怎么干,要做什么事情(定义中所谓的操作)。
  • Element-抽象元素:接口或者抽象类,声明接受哪一类的访问者访问,程序上是通过accept方法中的参数来定义的。
  • ConcreteElement-具体元素:实现accept方法,通常是visitor.visit(this),基本都形成一种模式了。
  • ObjectStructure-结构对象:元素产生者,一般容纳在多个不同类、不同接口的容器,如List、Set、Map等,在项目中,一般很少抽象出这个角色。

它的通用类图是:

 

3.访问者模式的使用场景

  • 一个对象结构(集合)包含很多类对象,它们有不同的接口,而你想对这些对象实施一些依赖于其具体类的操作,也就是说迭代器模式已经不能胜任的时候。
  • 需要对一个对象结构中的对象进行很多不同并且不想管的操作,而你想避免让这些操作污染这些对象的类。

总结一下,在这种地方你一定要考虑使用访问者模式:业务规则要求遍历多个不同的对象。这本身也是访问者模式的出发点,迭代器模式只能访问同类或同接口的数据(当然你可以使用instanceof来判断,不过不建议这么做),而访问者模式是对迭代器模式的扩充,可以遍历不同的对象,然后执行不同的操作,也就是针对访问的对象不同,执行不同的操作。

 

4.访问者模式的通用代码

package _19VisitorPattern;

/**
 * 抽象访问者
 */
public interface IVisitor {
	// 可以访问哪些对象
	public void visit(ConcreteElement1 el1);
	public void visit(ConcreteElement2 el2);
}
 
package _19VisitorPattern;

/**
 * 具体访问者
 */
public class Visitor implements IVisitor {

	// 访问el1元素
	@Override
	public void visit(ConcreteElement1 el1) {
		el1.doSomething();
	}

	// 访问el2元素
	@Override
	public void visit(ConcreteElement2 el2) {
		el2.doSomething();
	}

}
 
package _19VisitorPattern;

/**
 * 抽象元素类
 */
public abstract class Element {

	// 定义业务逻辑
	public abstract void doSomething();
	// 允许谁来访问
	public abstract void accept(IVisitor iVisitor);
}
 
package _19VisitorPattern;

/**
 * 具体元素类1
 */
public class ConcreteElement1 extends Element {

	// 完善业务逻辑
	@Override
	public void doSomething() {
		// 处理业务逻辑
	}

	// 允许哪个访问者访问
	@Override
	public void accept(IVisitor iVisitor) {
		iVisitor.visit(this);
	}

}
 
package _19VisitorPattern;

/**
 * 具体元素类2
 */
public class ConcreteElement2 extends Element {

	// 完善业务逻辑
	@Override
	public void doSomething() {
		// 处理业务逻辑
	}

	// 允许哪个访问者访问
	@Override
	public void accept(IVisitor iVisitor) {
		iVisitor.visit(this);
	}

}
 
package _19VisitorPattern;

import java.util.Random;

/**
 * 结构对象
 */
public class ObjectStructure {

	public static Element creatElement()
	{
		Random random = new Random();
		if(random.nextInt(100) > 50)
		{
			return new ConcreteElement1();
		}else{
			return new ConcreteElement2();
		}
	}
}
 
package _19VisitorPattern;

/**
 * 场景类
 */
public class Client {

	public static void main(String[] args) {
		for(int i=0;i<10;i++)
		{
			Element element = ObjectStructure.creatElement();
			// 接受访问者访问
			element.accept(new Visitor());
		}
	}

}

5.访问者模式的优点

  • 符合单一职责原则:具体元素角色负责数据的加载,而Visitor类则负责数据的展现,两个不同的职责非常明确地分离开来。
  • 优秀的扩展性:直接在Visitor中新增方法或者,直接新增Visitor访问者。
  • 灵活性非常高:由于职责分明,耦合性非常低,所以可以非常灵活的组合不同的数据和访问者。

6.访问者模式的缺点:

  • 具体元素对访问者公布细节:访问者需要访问一个类,就必须要求这个类公布一些方法和数据,也就是说访问者关注了其他类的内部细节,这是迪米特法则不建议的。
  • 具体元素变更困难:具体元素增加或删除任意成员变量都将影响到访问者的实现细节。
  • 违背了依赖倒置原则:访问者依赖的是具体的元素,而不是抽象元素,这破坏了依赖倒置原则,扩展比较困难。

7.访问者模式的扩展

统计功能
多个访问者
实现双分派:Java可以通过访问者模式实现支持双分派(其实Java是一门单分派语言)

 

8.最佳实践

访问者模式是一种集中规整模式,特别适用于大规模重构的项目,在这一个阶段需求已经非常清晰,原系统的功能点也已经明确,通过访问者模式可以非常容易把一些功能进行梳理,达到最终目的-功能集中化,如一个统一的报表运算、UI展现等,我们还可以与其他模式混编建立一套自己的过滤器或者拦截器。

猜你喜欢

转载自wangwengcn.iteye.com/blog/1729602
今日推荐