访问者模式
问题引出(测评系统的需求)
- 将观众分为男人和女人,对歌手进行测评,当看完某个歌手表演后,得到他们对该歌手不同的评价(评价 有不同的种类,比如 成功,失败等)
- 传统方案
传统方式的问题
- 如果系统比较小还是ok的,但是考虑系统的增加越来越多的功能时,对代码改动比较大,违反了ocp原则,不利于维护
- 扩展性不好,比如增加了新的人员类型,或者管理方法,都不好做
- 引出我们会使用新的设计模式-访问者模式
访问者模式基本介绍
- 访问者模式,封装一些作用与某种数据结构的各元素的操作,它可以在不改变数据结构的前提下定义作用于这些元素的新的操作
- 主要将数据结构与数据操作分离,解决数据结构和操作耦合性问题
- 访问者模式的基本工作原理是:在被访问的类里面加一个对外提供接待访问者的接口
- 访问者模式主要应用场景是:需要对一个对象结构中的对象进行很多不同操作(这些操作彼此没有关联),同时需要避免让这些操作“污染”这些对象的类,可以选用访问者模式解决
访问者模式的原理类图
对原理类图的说明-即(访问者模式的角色即职责)
- Visitor是抽象访问者,为该对象结构中的ConcreteElemenet的每一个类声明一个visit操作
- ConcreteVisitor:是一个具体的访问值 实现每个有Visitor声明的操作,是每个操作实现的部分
- ObjectStructure能枚举它的元素,可以提供一个高层的接口,用来允许访问者访问元素
- Element 定义一个accept方法,接收一个访问者对象
- ConcreteElement为具体元素,实现了accept方法
解决问题的类图:
代码分析:
package com.gduf.visitor;
/**
* @Author 晨边#CB
* @Date:created in 2020/4/5 16:42
* @Version V1.0
**/
public abstract class Action {
//得到男性的测评
public abstract void getManResult(Man man);
//得到女性的cep
public abstract void getWomanResult(Woman woman);
}
package com.gduf.visitor;
/**
* @Author 晨边#CB
* @Date:created in 2020/4/5 16:52
* @Version V1.0
**/
public class Client {
public static void main(String[] args) {
//创建ObjectStructure
ObjectStructure objectStructure = new ObjectStructure();
objectStructure.attach(new Man());
objectStructure.attach(new Woman());
//成功
Success success = new Success();
objectStructure.display(success);
System.out.println("===========================================");
Fail fail = new Fail();
objectStructure.display(fail);
System.out.println("==================给的是待定的测评(添加一个Wait类就行)=======================");
Wait wait = new Wait();
objectStructure.display(wait);
}
}
package com.gduf.visitor;
/**
* @Author 晨边#CB
* @Date:created in 2020/4/5 16:45
* @Version V1.0
**/
public class Fail extends Action {
@Override
public void getManResult(Man man) {
System.out.println("男人给歌手的评价是失败");
}
@Override
public void getWomanResult(Woman woman) {
System.out.println("女人给歌手的评价是失败~");
}
}
package com.gduf.visitor;
import com.gduf.uml.implementation.PersonService;
/**
* @Author 晨边#CB
* @Date:created in 2020/4/5 16:43
* @Version V1.0
**/
public class Man extends Person {
@Override
public void accept(Action action) {
action.getManResult(this);
}
}
package com.gduf.visitor;
import java.util.LinkedList;
import java.util.List;
/**
* @Author 晨边#CB
* @Date:created in 2020/4/5 16:50
* @Version V1.0
**/
public class ObjectStructure {
//维护一个集合
private List<Person> persons = new LinkedList<>();
//增加到list
public void attach(Person p){
persons.add(p);
}
//移除
public void detach(Person p){
persons.remove(p);
}
//显示测评情况
public void display(Action action){
for (Person p:persons){
p.accept(action);
}
}
}
package com.gduf.visitor;
/**
* @Author 晨边#CB
* @Date:created in 2020/4/5 16:43
* @Version V1.0
**/
public abstract class Person {
//提供一个方法,让访问者可以访问
public abstract void accept(Action action);
}
package com.gduf.visitor;
/**
* @Author 晨边#CB
* @Date:created in 2020/4/5 16:44
* @Version V1.0
**/
public class Success extends Action {
@Override
public void getManResult(Man man) {
System.out.println("男人给的评价的很成功~~");
}
@Override
public void getWomanResult(Woman woman) {
System.out.println("女人给的评价该歌手很成功~~");
}
}
package com.gduf.visitor;
/**
* @Author 晨边#CB
* @Date:created in 2020/4/5 16:55
* @Version V1.0
**/
//添加一个新的方法,待定的评价
public class Wait extends Action {
@Override
public void getManResult(Man man) {
System.out.println("男人给的评价是待定");
}
@Override
public void getWomanResult(Woman woman) {
System.out.println("女人给的评价的待定");
}
}
package com.gduf.visitor;
/**
* @Author 晨边#CB
* @Date:created in 2020/4/5 16:44
* @Version V1.0
**/
/**
* 说明
* 1.这里我们使用到了双分派,即首先在客户端程序中,将具体状态作为参数传递到Woman中(第一次分派)
* 2.然后Woman 类调用作为参数的具体的方法中的方法getWomanResult,同时将增加(this)作为参数传入,完成第二次分派
*/
public class Woman extends Person {
@Override
public void accept(Action action) {
action.getWomanResult(this);
}
}
应用案例的小结
- 上面提到的双分派,所谓双分派是指不管类怎么变化,我们都能找到期望的方法允许双分派意味着得到执行的操作取决于请求的种类和两个接收者的类型
- 以上述实例为例,假设我们要添加一个Wait状态类,考察Man类和Woman类的反应,由于使用了双分派,只需增加一个Action子类即可在客户端调用,不需要改动任何其他类的代码。
访问者模式的注意事项和细节
- 优点
- 访问者模式符合单一职责原则,让程序具有优秀的扩展性,灵活性非常高
- 访问者模式可以对功能进行统一,可以做报表,UI,拦截器,与过滤器,适用于数据结构相对稳定的系统
- 缺点
- 具体元素对访问者公布细节,也就是说访问者关注了其他类的内部细节,这是迪米特法则所不建议的,这样造成了具体元素变更比较困难
- 违背了依赖倒转原则。访问者依赖的是具体元素,而不是抽象元素
- 因此,如果一个系统有比较稳定的数据结构,又有经常变化的功能需求,那么访问者模式就是比较合适的