设计模式学习之不常用的访问者模式

定义：

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

角色职责：

• 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是一个还好办，多个呢？业务逻辑再复杂点呢？

• 违背了依赖倒置转原则

访问者依赖的是具体元素，而不是抽象元素，这破坏了依赖倒置原则，特别是在面向对象的编程中，抛弃了对接口的依赖，而直接依赖实现类，扩展比较难。

摘自《设计模式之禅》