访问者模式
无场景，不设计，有这样的一个需求(评测系统)：
将观众分为学生和在职人员，对歌手进行测评，当看完某个歌手表演后，得到他们对该歌手不同的评价(评价 有不同的种类，比如 成功、失败 等)
传统的解决方法：
将评测人员做一个抽象类，然后在按照不同类型的子类来继承它
类图：
按照传统方案的解决方式相信大家也是有了一定的思路了，。但是传统方法解决是有一定的弊端
传统方案的问题分析：
- 系统比较小，还是ok的，但是考虑系统增加越来越多新的功能时，对代码改动较大，违反了ocp原则， 不利于维护
- 扩展性不好，比如 增加了 新的人员类型，或者管理方法，都不好做
针对上述方案的弊端引出了我们本次要讲的主题.访问者模式
访问者模式
基本概念
- 访问者模式（Visitor Pattern）：封装一些作用于某种数据结构的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作
- 主要将数据结构和数据操作分离，解决
数据结构和操作耦合性的问题 - 访问者模式基本的
工作原理是：在被访问的类里面加一个对外提供接待访问的接口 - 访问者模式主要应用场景：需要对一个对象结构中的对象进行很多种不同的操作（这些操作彼此没有关联），同时要避免这些操作"污染"这些对象那个的类，可以选用访问者模式解决.
访问者模式的原理类图
类图分析
- Visitor 是抽象访问者，为该对象结构中的ConcreteElement的每一个类声明一个visit操作
- ConcreteVisitor ：是一个具体的访问者 实现每个有Visitor 声明的操作，是每个操作实现的部分.
- ObjectStructure 能枚举它的元素， 可以提供一个高层的接口，用来允许访问者访问元素 4>) Element 定义一个accept 方法，接收一个访问者对象
- ConcreteElement 为具体元素，实现了accept 方法
好了讲了这么多的理论知识：估计也是迷迷糊糊的，直接针对上述案例来撸代码吧，使用访问者模式解决评测系统的问题：
应用案例类图：
代码展示
- Action
public abstract class Action {
//得到男性 的测评
public abstract void getManResult(Man man);
//得到女的 测评
public abstract void getWomanResult(Woman woman);
}
- Person
public abstract class Person {
//提供一个方法，让访问者可以访问
public abstract void accept(Action action);
}
- Man（继承Person）
public class Man extends Person {
@Override
public void accept(Action action) {
// TODO Auto-generated method stub
action.getManResult(this);
}
}
- Woman（继承Person）
说明:
- 这里我们使用到了双分派, 即首先在客户端程序中，将具体状态作为参数传递Woman中(第一次分派)
- 然后Woman 类调用作为参数的 "具体方法" 中方法getWomanResult, 同时将自己(this)作为参数传入，完成第二次的分派
public class Woman extends Person{
@Override
public void accept(Action action) {
// TODO Auto-generated method stub
action.getWomanResult(this);
}
}
- Success（继承Action）
public class Success extends Action {
@Override
public void getManResult(Man man) {
// TODO Auto-generated method stub
System.out.println(" 男人给的评价该歌手很成功 !");
}
@Override
public void getWomanResult(Woman woman) {
// TODO Auto-generated method stub
System.out.println(" 女人给的评价该歌手很成功 !");
}
}
- Fail（继承Action）
public class Fail extends Action {
@Override
public void getManResult(Man man) {
// TODO Auto-generated method stub
System.out.println(" 男人给的评价该歌手失败 !");
}
@Override
public void getWomanResult(Woman woman) {
// TODO Auto-generated method stub
System.out.println(" 女人给的评价该歌手失败 !");
}
}
- ObjectStructure（数据结构，管理很多人（Man , Woman））
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);
}
}
}
- Client（调用者）
public class Client {
public static void main(String[] args) {
// TODO Auto-generated method stub
//创建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);
}
}
以上代码就是访问者模式的简单使用。但是有的小伙伴就会有疑问，这也没有体现出它的优越之处。请看接下来的需求：
- 假设我们要添加一个Wait的状态类，考察Man类和Woman类的反应
由于使用了
双分派，只需增加一个Action子类即可在客户端调用即可，不需要改动任何其他类的代码。
- Wait（新增的状态,也要继承Action）
public class Wait extends Action {
@Override
public void getManResult(Man man) {
// TODO Auto-generated method stub
System.out.println(" 男人给的评价是该歌手待定 ..");
}
@Override
public void getWomanResult(Woman woman) {
// TODO Auto-generated method stub
System.out.println(" 女人给的评价是该歌手待定 ..");
}
}
Client端只需要增加两行代码即可测试
Wait wait = new Wait();
objectStructure.display(wait);
到这里是不是感觉到访问者模式的优点。
简单总结一下吧：
优点：
- 访问者模式符合单一职责原则、让程序具有优秀的
扩展性、灵活性非常高 - 访问者模式可以对功能进行统一，可以做报表、UI、拦截器与过滤器，适用于数据结构相对稳定的系统
缺点：
- 具体元素对访问者公布细节，也就是说访问者关注了其他类的内部细节，这是
迪米特法则所不建议的, 这样造成了具体元素变更比较困难 - 违背了
依赖倒转原则。访问者依赖的是具体元素，而不是抽象元素 - 因此，如果一个系统有比较
稳定的数据结构，又有经常变化的功能需求，那么访问者模式就是比较合适的
本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。
原始发表：2021-07-04，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读
目录
相关产品与服务
腾讯云 BI
腾讯云 BI（Business Intelligence，BI）提供从数据源接入、数据建模到数据可视化分析全流程的BI能力，帮助经营者快速获取决策数据依据。系统采用敏捷自助式设计，使用者仅需通过简单拖拽即可完成原本复杂的报表开发过程，并支持报表的分享、推送等企业协作场景。
腾讯云开发者
