定义:
封装一些作用于某种数据结构中的各元素的操作,它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
角色职责:
- Visitor抽象访问者:
抽象类或者接口,声明访问者可以访问哪些元素,具体到程序中就是visit方法的参数定义哪些对象是可以被访问的。
- ConcreteVisitor具体访问者:
它影响访问者访问到一个类后该怎么干,要做什么事情。
- Element抽象元素:
接口或者抽象类,声明接受哪一类访问者访问,程序上是通过accept方法中的参数来定义的。
- ConcreteElement具体元素:
实现accept方法,通常是visitor.visit(this),基本上都形成了一种模式了。
- ObjectStruture结构对象:
元素产生者,一般容纳在多个不同类、不同接口的容器,如List、Set、Map等,在项目中,一般很少抽象出这个角色。
通用源码:
/**
* 访问者模式
* 抽象访问者
*/
public interface IVisitor {
//可以访问哪个对象
public void visit(ConcreteElement1 element1);
public void visit(ConcreteElement2 element2);
}
/**
* 访问者模式
* 具体访问者
*/
public class Visitor implements IVisitor {
//访问element1
@Override
public void visit(ConcreteElement1 element1) {
element1.doSomething();
}
//访问element2
@Override
public void visit(ConcreteElement2 element2) {
element2.doSomething();
}
}
/**
* 访问者模式
* 抽象元素
*/
public abstract class Element {
//定义业务逻辑
public abstract void doSomething();
//允许谁来访问
public abstract void accept(IVisitor visitor);
}
/**
* 访问者模式
*具体元素
*/
public class ConcreteElement1 extends Element{
//具体业务逻辑
@Override
public void doSomething() {
}
//允许具体哪个访问者访问
@Override
public void accept(IVisitor visitor) {
visitor.visit(this);
}
}
/**
* 访问者模式
*具体元素
*/
public class ConcreteElement2 extends Element{
//具体业务逻辑
@Override
public void doSomething() {
}
//允许具体哪个访问者访问
@Override
public void accept(IVisitor visitor) {
visitor.visit(this);
}
}
import java.util.Random;
/**
* 访问者模式
* 结构对象:存储访问者
*/
public class ObjectStruture {
//对象模拟器
public static Element createElement(){
Random random = new Random();
if(random.nextInt(100) >50){
return new ConcreteElement1();
}else {
return new ConcreteElement2();
}
}
}
/**
* 访问者模式
* 场景类
*/
public class Client {
public static void main(String [] args){
for (int i = 0; i <10 ; i++) {
//获取元素类型
Element element = ObjectStruture.createElement();
//接受访问者访问
element.accept(new Visitor());
}
}
}
总结:
- 符合单一职责原则
具体元素角色也就是Employee抽象类的两个子类负责数据的加载,而Visitor类则负责报表的展现,两个不同的职责非常明确地分离开来,各自演绎变化。
- 优秀的扩展性
由于职责分开,继续增加对数据的操作是非常快捷的,例如,现在要增加一份给大老板的报表,这份报表格式又有所不同,直接在Visitor中增加一个方法,传递数据后进行整理打印。
- 灵活性非常高
涉及独立的场景交给访问这更方便
- 具体元素对访问者公布细节
访问者要访问一个类就必然要求这个类公布一些方法和数据,也就是说访问者关注了其他类的内部细节,这是迪米特法则所不建议的。
- 具体元素变更比较困难
具体元素角色的增加、删除、修改都是比较困难的,就上面那个例子,你想想,你要是想增加一个成员变量,如年龄age,Visitor就需要修改,如果Visitor是一个还好办,多个呢?业务逻辑再复杂点呢?
- 违背了依赖倒置转原则
访问者依赖的是具体元素,而不是抽象元素,这破坏了依赖倒置原则,特别是在面向对象的编程中,抛弃了对接口的依赖,而直接依赖实现类,扩展比较难。
摘自《设计模式之禅》