引言

访问者模式是遵循单一职责原则，将行为和属性分离的一种设计模式，它可以在不改变元素结构的前提下定义元素新的操作。类比到现实当中就像博物馆，它是固定不变的，其中有各种各样的展品，而我们就是访客，可以是参观、可以是打扫、也可以是管理。同样访客模式正是具有了这样一个特点。

正文

访客模式含有五大角色，分别是：

抽象元素（AbstractElement）：抽象类或接口，定义一个accept方法，供访问者访问
具体元素（ConcreteElement）：访问者待访问的对象，实现accept方法
抽象访问者（AbstractVisitor）：抽象类或接口，定义visit方法，访问不同的元素
具体访问者（ConcreteVisitor）：实现visit方法，如何访问元素
结构对象（ObjectStruct）：组合元素类，交给访问者

通过这五个角色我们便能将变化的部分（行为）独立到访问者类中，这样增加新的行为就不会影响到元素类了。那该如何实现呢？下面我以一个汽车零件的例子来说明。

Coding

首相是元素族，即汽车零件：

public abstract class Components {

    protected String brand;

    public Components(String brand) {
        this.brand = brand;
    }

    public String getBrand() {
        return brand;
    }

    public void setBrand(String brand) {
        this.brand = brand;
    }

    public abstract void accept(IVisitor visitor);

}

public class Engine extends Components {

    private String power;

    public Engine(String brand, String power) {
        super(brand);
        this.power = power;
    }

    public String getPower() {
        return power;
    }

    public void setPower(String power) {
        this.power = power;
    }

    @Override
    public void accept(IVisitor visitor) {
        visitor.visit(this);
    }

}

public class CarBody extends Components {

    private String color;

    public String getColor() {
        return color;
    }

    public void setColor(String color) {
        this.color = color;
    }

    public CarBody(String brand, String color) {
        super(brand);
        this.color = color;
    }

    @Override
    public void accept(IVisitor visitor) {
        visitor.visit(this);
    }
}

这里只是为了说明，所以只列出了车身和引擎部件，它们公用的是品牌属性，而其分别含有颜色和功率属性。

public interface IVisitor {

    void visit(CarBody carBody);

    void visit(Engine engine);

}

public class BugattiModifiedVisitor implements IVisitor {

    @Override
    public void visit(CarBody carBody) {
        System.out.println("改装前品牌：" + carBody.getBrand() + "，改装前车身颜色：" + carBody.getColor());
        carBody.setBrand("布加迪威航");
        carBody.setColor("black");
        System.out.println("改装后品牌：" + carBody.getBrand() + "，改装后车身颜色：" + carBody.getColor());
    }

    @Override
    public void visit(Engine engine) {
        System.out.println("改装前品牌：" + engine.getBrand() + "，改装前功率：" + engine.getPower());
        engine.setPower("500");
        engine.setBrand("布加迪威航");
        System.out.println("改装后品牌：" + engine.getBrand() + "，改装后功率：" + engine.getPower());
    }
}

public class BenzModifiedVisitor implements IVisitor {

    @Override
    public void visit(CarBody carBody) {
        System.out.println("改装前品牌：" + carBody.getBrand() + "，改装前车身颜色：" + carBody.getColor());
        carBody.setBrand("奔驰");
        carBody.setColor("blue");
        System.out.println("改装后品牌：" + carBody.getBrand() + "，改装后车身颜色：" + carBody.getColor());
    }

    @Override
    public void visit(Engine engine) {
        System.out.println("改装前品牌：" + engine.getBrand() + "，改装前功率：" + engine.getPower());
        engine.setPower("300");
        engine.setBrand("奔驰");
        System.out.println("改装后品牌：" + engine.getBrand() + "，改装后功率：" + engine.getPower());
    }

}

这里IVisitor接口中我定义了两个visit方法，分别访问了CarBody和Engine，同时我实现了两个访问者：布加迪威航改装者和奔驰改装者，分别将原始车辆部件替换为布加迪威航和奔驰的部件。你需要思考的是为什么不定义一个visit方法传入一个Components类，这样增加新元素类不就不用修改接口了？

public class ObjectStructure {

    public static List<Components> getComponents() {
        String brand = "大众";
        CarBody carBody = new CarBody(brand, "红色");
        Engine engine = new Engine(brand, "100");

        List<Components> list = new ArrayList<>();
        list.add(carBody);
        list.add(engine);
        return list;
    }
}

最后是结构对象类，这里只是简单的组合各元素类到一个集合中，方便访问者依次访问。至此，就实现了一个标准的访问者模式，我们增加新的行为（比如增加一个其它品牌的访问者或者是修理工访问者）对元素类不会有任何的影响，只需要实现IVisitor接口即可；不过，刚刚你也注意到，在访问者接口中我们定义了两个方法，分别访问不同的元素，这样，一旦增加新的元素类，我们就不得不修改访问者接口，同时每个具体的访问者也不得不实现新增的行为，这简直是灾难，所以这就是访问者模式的显著缺点，它仅适合元素类固定不变的情况，所以大多也都是在重构项目时更适合使用（因为此时更能够判断元素类的变化情况）。当然这个缺点我们也可以完善，在访问者接口方法中传入抽象的元素类型而不是具体的元素类型即可解决，但是这样相当于所有的元素类都具有相同的操作，违背了访问者模式的初衷（单一职责）。或许我们可以通过向下强制转型并使用if else或者是责任链模式来解决，但这样势必会导致我们的类结构变得异常复杂，因此我们在考虑使用访问者模式的时候一定要慎重。

总结

访问者模式可以帮助我么将变化的行为独立到元素的外部，但和其它设计模式一样都有其优点和缺点，在实际开发中，我们不要过度设计，想用而用，而要真正的考虑各种模式的使用范围。

设计之禅——访问者模式

引言

正文

Coding

总结