一、定义
访问者模式(Visitor Pattern)是一个相对简单的模式,其定义如下:Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. (封装一些作用于某种 数据结构中的各元素的操作,它可以在不改变数据结构的前提下定义作用于这些元素的新的 操作。)
访问者模式的通用类图如图所示。
访问者模式的通用类图
我们来看这几个角色的职责。
Visitor——抽象访问者
抽象类或者接口,声明访问者可以访问哪些元素,具体到程序中就是visit方法的参数定 义哪些对象是可以被访问的。
ConcreteVisitor——具体访问者
它影响访问者访问到一个类后该怎么干,要做什么事情。
Element——抽象元素
接口或者抽象类,声明接受哪一类访问者访问,程序上是通过accept方法中的参数来定 义的。
ConcreteElement——具体元素
实现accept方法,通常是visitor.visit(this),基本上都形成了一种模式了。
ObjectStruture——结构对象
元素产生者,一般容纳在多个不同类、不同接口的容器,如List、Set、Map等,在项目 中,一般很少抽象出这个角色。
//抽象元素public abstract class Element { //定义业务逻辑 public abstract void doSomething(); //允许谁来访问 public abstract void accept(IVisitor visitor); }//具体元素public class ConcreteElement1 extends Element{ //完善业务逻辑 public void doSomething(){ //业务处理 } //允许那个访问者访问 public void accept(IVisitor visitor){ visitor.visit(this); } }public class ConcreteElement2 extends Element{ //完善业务逻辑 public void doSomething(){ //业务处理 } //允许那个访问者访问 public void accept(IVisitor visitor){ visitor.visit(this); } }//抽象访问者public interface IVisitor { //可以访问哪些对象 public void visit(ConcreteElement1 el1); public void visit(ConcreteElement2 el2); }//具体访问者public class Visitor implements IVisitor { //访问el1元素 public void visit(ConcreteElement1 el1) { el1.doSomething(); } //访问el2元素 public void visit(ConcreteElement2 el2) { el2.doSomething(); } }//结构对象public class ObjectStruture { //对象生成器,这里通过一个工厂方法模式模拟 public static Element createElement(){ Random rand = new Random(); if(rand.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 el = ObjectStruture.createElement(); //接受访问者访问 el.accept(new Visitor()); } } }
二、应用
2.1 优点
符合单一职责原则
具体元素角色也就是Employee抽象类的两个子类负责数据的加载,而Visitor类则负责报 表的展现,两个不同的职责非常明确地分离开来,各自演绎变化。
优秀的扩展性
由于职责分开,继续增加对数据的操作是非常快捷的,例如,现在要增加一份给大老板 的报表,这份报表格式又有所不同,直接在Visitor中增加一个方法,传递数据后进行整理打 印。
灵活性非常高
2.2 缺点
具体元素对访问者公布细节
访问者要访问一个类就必然要求这个类公布一些方法和数据,也就是说访问者关注了其 他类的内部细节,这是迪米特法则所不建议的。
具体元素变更比较困难
具体元素角色的增加、删除、修改都是比较困难的,就上面那个例子,你想想,你要是 想增加一个成员变量,如年龄age,Visitor就需要修改,如果Visitor是一个还好办,多个呢? 业务逻辑再复杂点呢?
违背了依赖倒置转原则
访问者依赖的是具体元素,而不是抽象元素,这破坏了依赖倒置原则,特别是在面向对象的编程中,抛弃了对接口的依赖,而直接依赖实现类,扩展比较难。
2.3 使用场景
一个对象结构包含很多类对象,它们有不同的接口,而你想对这些对象实施一些依赖 于其具体类的操作,也就说是用迭代器模式已经不能胜任的情景。
需要对一个对象结构中的对象进行很多不同并且不相关的操作,而你想避免让这些操 作“污染”这些对象的类。
总结一下,在这种地方你一定要考虑使用访问者模式:业务规则要求遍历多个不同的对 象。这本身也是访问者模式出发点,迭代器模式只能访问同类或同接口的数据(当然了,如 果你使用instanceof,那么能访问所有的数据,这没有争论),而访问者模式是对迭代器模式 的扩充,可以遍历不同的对象,然后执行不同的操作,也就是针对访问的对象不同,执行不 同的操作。访问者模式还有一个用途,就是充当拦截器(Interceptor)角色,这个我们将在 混编模式中讲解。
作者:端木轩
链接:https://www.jianshu.com/p/01727957e4ac
共同学习,写下你的评论
评论加载中...
作者其他优质文章