程序员必知的23种设计模式之访问者模式

1. 模式引出-测评系统需求

在歌手评选的系统中，有歌手和观众，观众分为男人和女人，对歌手进行测评，当看完某个歌手表演后，得到他们对该歌手不同的评价(评价 有不同的种类，比如 成功、失败 等)

要求：

1. 每一种评价都需要一个类

2. 各种观众也都都各需要一个类

3. 观众类依赖评价类做出评价，不同种类的观众评价内容不同

4. 评价的种类要求易扩展

2. 传统方案

1. 可以得知，不同的观众类的评价方法不会有区别，所以可以复用评价的方法，构造一个Person父类，设子类观众Man类和Woman类。定义一个Action标记接口，实现子类为Fail和Success评价，本例为评价类为空类

2. 在父类中定义accept方法，判读传入评价类的类型，并依照判断的结果做出不同的输出。

2.1 传统方式代码

Action.java

// 一个评价类的标记接口
public interface Action {
}

Fail.java

// 具体评价类，本例中不需要内容实现
public class Fail implements Action{
}

Success.java

// 具体评价类，本例中不需要内容实现
public class Success implements Action{
}

Person.java

// 观众类的父类
public abstract class Person {
	public abstract void accept(Action a);
}

Man.java

// 具体观众类
public class Man extends Person {

	@Override
	public void accept(Action a) {
		if (a instanceof Success) {
			System.out.println("man:success");
		} else {
			System.out.println("man:fail");
		}

	}

}

Woman.java

// 具体观众类
public class Woman extends Person {

	@Override
	public void accept(Action a) {
		if (a instanceof Success) {
			System.out.println("woman:success");
		} else {
			System.out.println("woman:fail");
		}

	}

}

测试Main.java

public class Main {
	public static void main(String[] args) {
		Action fail = new Fail();
		Person man = new Man();
		man.accept(fail);
		
	}
}

输出结果

传统方式的问题分析

1. 如果系统比较小，还是ok的，但是考虑系统增加越来越多新的功能时，对代码改动较大，违反了ocp原则， 不利于维护

2. 扩展性不好，如果评价类型很多，需要增加或删除了某个评价的类型（需要修改if-else，很麻烦），或者管理方法，都不好做

3. 引出我们会使用新的设计模式 – 访问者模式

3. 访问者模式基本介绍

1. 访问者模式（Visitor Pattern），封装一些作用于某种数据结构的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

2. 主要将数据结构与数据操作分离，解决 数据结构和操作耦合性问题

3. 访问者模式的基本工作原理是：在被访问的类里面加一个对外提供接待访问者的接口

4. 访问者模式主要应用场景是：需要对一个对象结构中的对象进行很多不同操作(这些操作彼此没有关联)，同时需要避免让这些操作"污染"这些对象的类，可以选用访问者模式解决

3.1 UML原理类图

3.2 对原理类图的说明- 即(访问者模式的角色及职责)

1. Visitor 是抽象访问者，为该对象结构中的ConcreteElement的每一个类声明一个visit操作(相当于上例评价类的父类)

2. ConcreteVisitor ：是一个具体的访问值 实现每个有Visitor 声明的操作，是对每个元素操作实现的部分.（具体评价类）

3. ObjectStructure 能枚举它的元素， 可以提供一个高层的接口，用来允许访问者访问元素（被增加方法的稳定数据结构，其中有各种不同的元素，用来管理被访问者）

4. Element 定义一个accept 方法，接收一个访问者对象（观众父类）

5. ConcreteElement 为具体元素，实现了accept 方法（具体观众）

4. 方案修改

观众类的数据结构稳定的，而评价类是容易变化的。

访问者是评价类，接受访问的是观众类，二者的访问和接受访问的方法都需要在父类或接口中定义。

评价类的接口必须定义每个观众类的访问方法。

观众类接收评价类对象时只需要接受对象的访问方法即可。（注意类型要对应）

修改后的UML类图

Action.java

// 评价类接口：定义每个观众的访问方法
public interface Action {
	public void visitMan(Man man);
	public void visitWoman(Woman woman);
}

Fail.java

// 具体评价类：具体访问者
public class Fail implements Action{

	@Override
	public void visitMan(Man man) {
		System.out.println("man:fail");
	}

	@Override
	public void visitWoman(Woman woman) {
		System.out.println("woman:fail");
	}

}

Success.java

// 具体评价类：具体访问者
public class Success implements Action{

	@Override
	public void visitMan(Man man) {
		System.out.println("man:success");
	}

	@Override
	public void visitWoman(Woman woman) {
		System.out.println("woman:success");
	}

}

Man.java

// 具体观众类
public class Man extends Person {

	@Override
	public void accept(Action a) {
		a.visitMan(this);
	}

}

Woman.java

// 具体观众类
//说明
//1. 这里我们使用到了双分派, 即首先在客户端程序中，将具体状态作为参数传递Woman中(第一次分派)
//2. 然后Woman 类调用作为参数的 "具体方法" 中方法visitWoman, 同时将自己(this)作为参数
// 传入，完成第二次的分派
public class Woman extends Person {

	@Override
	public void accept(Action a) {
		a.visitWoman(this);
	}

}

ObjectStruture.java

// 具体观众集合类，可以做统一操作
public class ObjectStruture {
	private List<Person> list = new ArrayList<Person>();

	public void addPerson(Person p) {
		list.add(p);
	}

	public void startAction(Action a) {
		for (Person p : list) {
			p.accept(a);
		}
	}

}

测试Main.java

public class Main {
	public static void main(String[] args) {
		ObjectStruture objs = new ObjectStruture();
		objs.addPerson(new Man());
		objs.addPerson(new Man());
		objs.addPerson(new Woman());
		objs.startAction(new Success());
		
		
	}
}

输出结果

5. 双分派

所谓双分派是指不管类怎么变化，我们都能找到期望的方法运行，双分派意味着得到执行的操作取决于请求的种类和两个接收者的类型

以上述实例为例，假设我们要添加一个Wait的状态类，考察Man类和Woman类的反应，由于使用了双分派，只需增加一个Action子类即可在客户端调用即可，不需要改动任何其他类的代码。

6. 访问者模式的注意事项和细节

6.1 优点

1. 访问者模式符合单一职责原则、让程序具有优秀的扩展性、灵活性非常高

2. 访问者模式可以对功能进行统一，可以做报表、UI、拦截器与过滤器，适用于数据结构相对稳定的系统

6.2 缺点

1. 具体元素对访问者公布细节，也就是说访问者关注了其他类的内部细节，这是迪米特法则所不建议的, 这样造成了具体元素变更比较困难

2. 违背了依赖倒转原则。访问者依赖的是具体元素，而不是抽象元素

3. 因此，如果一个系统有比较稳定的数据结构，又有经常变化的功能需求，那么访问者模式就是比较合适的.