访问者模式的使用

一、模式介绍

访问者模式通常包含如下几个角色：

• 抽象元素，定义元素接受访问者访问的方法；
• 具体元素，提供接受访问者访问的具体实现，以及自身的一些操作；
• 抽象访问者，定义多个visit方法用来访问每一个具体元素，理论上visit方法个数等于具体元素个数；因此要求该模式使用场景是元素稳定不变的。
• 具体访问者，实现对具体元素操作的访问；
• 结构对象，维护具体元素的集合，提供方法接受具体访问者对集合中的所有元素进行访问；

通用的实现代码如下：

/**
 * 抽象元素
 * 定义接受访问者访问的方法
 * 所有具体元素都支持被访问者访问
 */
public interface IElement {
    void accept(IVisitor visitor);
}

/**
 * 具体元素A
 */
@Slf4j
public class ConcreteElementA implements IElement{
    @Override
    public void accept(IVisitor visitor) {
        // 访问者进行访问
        visitor.visit(this);
    }

    public void operation(){
        log.info("ConcreteElementA operation");
    }
}

/**
 * 具体元素B
 */
@Slf4j
public class ConcreteElementB implements IElement{
    @Override
    public void accept(IVisitor visitor) {
        // 访问者进行访问
        visitor.visit(this);
    }

    public void operation(){
        log.info("ConcreteElementB operation");
    }
}

/**
 * 抽象访问者
 */
public interface IVisitor {
    /**
     * 定义visit方法访问每一个具体的元素
     * 理论上visit方法个数和具体元素的个数是相等的
     * @param element
     */
    void visit(ConcreteElementA element);
    void visit(ConcreteElementB element);
}

/**
 * 具体访问者，实现对具体元素的访问操作
 */
public class ConcreteVisitor implements IVisitor{
    @Override
    public void visit(ConcreteElementA element) {
        element.operation();
    }

    @Override
    public void visit(ConcreteElementB element) {
        element.operation();
    }
}

public class ObjectStructure {
    private List<IElement> list = new ArrayList<>();

    /**
     * 需要被访问的具体元素初始化时都装入集合中
     */
    {
        this.list.add(new ConcreteElementA());
        this.list.add(new ConcreteElementB());
    }

    /**
     * 接待某个具体的访问者
     * @param visitor
     */
    public void accept(IVisitor visitor){
        // 带访问者依次参观具体元素
        for (IElement element : this.list) {
            element.accept(visitor);
        }
    }
}

@Slf4j
public class Main {
    public static void main(String[] args) {
        ObjectStructure collection = new ObjectStructure();
        IVisitor jack = new ConcreteVisitor();
        // 接待jack这个访问者
        collection.accept(jack);
    }
}

我们将如上的案例来做一个实际场景的类比:

• ObjectStructure相当于一个家族的管家，具体元素类相当于每个房间里面的主人，家族里面主人的个数肯定是固定的，然后访问者来家族进行访问的时候，由管家进行接待accept(visitor)；
• 然后管家带领访问者依次去每个房间拜访主人element.accept(visitor)；
• 每个主人需要同意accept(visitor)访问者访问后，访问者才可以进行对当前主人的访问visitor.visit(this)；
• 然后这个主人才和访问者进行交流，展示自己operation；

在这样的设计模式中，任何访问者想来拜访，只要让管家去接待一下即可，每个房间的主人们则完全不用操心，只需要固定地接受拜访并展示自己即可，对访问者的扩展十分方便。与此同时，倘若每个房间的主人有多项技能的话（唱歌、跳舞、吟诗、作画......），访问者可以自己定义想拜访主人都需要为自己展示什么才能，只要过了管家这一关即可，因为必须要管家给安排。

二、使用场景

• JDK的NIO中的FileVisitor接口；
• Spring中的BeanDefinitionVisitor类；

三、模式总结

3.1 优点

• 解耦了数据结构和数据操作；
• 可以很方便地扩展访问者角色，实现对不同数据集的不同操作，扩展性良好；
• 元素具体类型可以是多样的，访问者均可操作；
• 各个角色职责分离，符合单一职责原则；

3.2 缺点

• 无法灵活增加元素类型，否则就得频繁改动访问者，违反了开闭原则；
• 元素行为增删困难，需要改动访问者的调用行为，违反了开闭原则；
• 访问者直接耦合了具体元素类，而没有以来抽象，违背了依赖倒置原则；