认真学习设计模式之访问者模式(Visitor Pattern)

简介: 认真学习设计模式之访问者模式(Visitor Pattern)

【1】概述

① 定义

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


访问者模式的基本工作原理是:在被访问的类里面加一个对外提供接待访问者的接口。主要将数据结构与数据操作分离,解决数据结构和操作耦合性问题。


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

② UML类图

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


Visitor 是抽象访问者,为该对象结构中的ConcreteElement 的每一个类声明一个visit 操作

ConcreteVisitor :是一个具体的访问值实现每个有Visitor 声明的操作,是每个操作实现的部分.

ObjectStructure 能枚举它的元素, 可以提供一个高层的接口,用来允许访问者访问元素

Element 定义一个accept 方法,接收一个访问者对象

ConcreteElement 为具体元素,实现了accept 方法

【2】案例分析

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

① 传统方式

如定义Person与Man、Woman,然后分别实现成功、失败、待定等方法。


传统方式的问题是如果系统比较小,还是ok 的,但是考虑系统增加越来越多新的功能时,对代码改动较大,违反了ocp (开闭原则)原则, 不利于维护。另外其扩展性不好,比如增加了新的人员类型,或者管理方法,都不好做。


这里引出我们会使用新的设计模式– 访问者模式。


② 访问者模式

① 定义Element与实现

//Element
public abstract class Person {
  //提供一个方法,让访问者可以访问
  public abstract void accept(Action action);
}
// ConcreteElement
public class Man extends Person {
  //提供一个方法,让访问者可以访问
  @Override
  public void accept(Action action) {
    action.getManResult(this);
  }
}
// ConcreteElement
public class Woman extends Person{
  //提供一个方法,让访问者可以访问
  @Override
  public void accept(Action action) {
    action.getWomanResult(this);
  }
}


这里我们使用到了双分派, 即首先在客户端程序中,将具体状态(Action的子类)作为参数传递Woman中(第一次分派).然后Woman 类调用作为参数的 “具体方法” 中方法getWomanResult, 同时将自己(this)作为参数传入,完成第二次的分派。


② 定义访问者Action

// Visitor
public abstract class Action {
  //得到男性 的测评
  public abstract void getManResult(Man man); 
  //得到女的 测评
  public abstract void getWomanResult(Woman woman);
}
// 具体的行为实现
public class Fail extends Action {
  @Override
  public void getManResult(Man man) {
    System.out.println(" 男人给的评价该歌手失败 !");
  }
  @Override
  public void getWomanResult(Woman woman) {
    System.out.println(" 女人给的评价该歌手失败 !");
  }
}
// 具体的行为实现
public class Success extends Action {
  @Override
  public void getManResult(Man man) {
    System.out.println(" 男人给的评价该歌手很成功 !");
  }
  @Override
  public void getWomanResult(Woman woman) {
    System.out.println(" 女人给的评价该歌手很成功 !");
  }
}
// 具体的行为实现
public class Wait extends Action {
  @Override
  public void getManResult(Man man) {
    System.out.println(" 男人给的评价是该歌手待定 ..");
  }
  @Override
  public void getWomanResult(Woman woman) {
    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);
    }
  }
}

④ 客户端测试

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 = new Wait();
    objectStructure.display(wait);
  }
}


打印结果:

 男人给的评价该歌手很成功 !
 女人给的评价该歌手很成功 !
===============
 男人给的评价该歌手失败 !
 女人给的评价该歌手失败 !
=======给的是待定的测评========
 男人给的评价是该歌手待定 ..
 女人给的评价是该歌手待定 ..


如果多增加一种行为,那么只需定义对应类继承Action并实现抽象方法即可。

⑤ UML类图

③ 总结


优点


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

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

缺点


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

违背了依赖倒转原则。访问者依赖的是具体元素,而不是抽象元素。如这里访问者Fail需要具体的Man或者Woman,而不是抽象的Person。

因此,如果一个系统有比较稳定的数据结构,又有经常变化的功能需求(也就是说man woman固定,行为/操作变化),那么访问者模式就是比较合适的。


迪米特法则又叫最少知道原则,一个对象应当对其他对象有尽可能少的了解。迪米特法则简单的说就是如何做到”低耦合”,门面模式和调停者模式就是对迪米特法则的践行。

一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂,都应该将逻辑封装在方法的内部,通过public方法提供给外部。这样当被依赖的类变化时,才能最小的影响该类。

目录
相关文章
|
4月前
|
设计模式 算法 Java
【设计模式】JAVA Design Patterns——Acyclic Visitor(非循环访问者模式)
【设计模式】JAVA Design Patterns——Acyclic Visitor(非循环访问者模式)
|
3月前
|
设计模式 存储 算法
设计模式学习心得之五种创建者模式(2)
设计模式学习心得之五种创建者模式(2)
29 2
|
3月前
|
设计模式 uml
设计模式学习心得之前置知识 UML图看法与六大原则(下)
设计模式学习心得之前置知识 UML图看法与六大原则(下)
25 2
|
3月前
|
设计模式
设计模式-05建造者模式(Builder Pattern)
设计模式-05建造者模式(Builder Pattern)
|
3月前
|
设计模式 安全 Java
设计模式学习心得之五种创建者模式(1)
设计模式学习心得之五种创建者模式(1)
24 0
|
3月前
|
设计模式 数据可视化 程序员
设计模式学习心得之前置知识 UML图看法与六大原则(上)
设计模式学习心得之前置知识 UML图看法与六大原则(上)
28 0
|
4月前
|
设计模式 安全 Java
【设计模式】JAVA Design Patterns——Curiously Recurring Template Pattern(奇异递归模板模式)
该文介绍了一种C++的编程技巧——奇异递归模板模式(CRTP),旨在让派生组件能继承基本组件的特定功能。通过示例展示了如何创建一个`Fighter`接口和`MmaFighter`类,其中`MmaFighter`及其子类如`MmaBantamweightFighter`和`MmaHeavyweightFighter`强制类型安全,确保相同重量级的拳手之间才能进行比赛。这种设计避免了不同重量级拳手间的错误匹配,编译时会报错。CRTP适用于处理类型冲突、参数化类方法和限制方法只对相同类型实例生效的情况。
【设计模式】JAVA Design Patterns——Curiously Recurring Template Pattern(奇异递归模板模式)
|
4月前
|
设计模式 安全 Java
【JAVA学习之路 | 基础篇】单例设计模式
【JAVA学习之路 | 基础篇】单例设计模式
|
4月前
|
设计模式 安全 Java
【设计模式】字节三面:请举例阐释访问者模式
【设计模式】字节三面:请举例阐释访问者模式
29 2
|
4月前
|
设计模式 安全 Java
【设计模式学习】单例模式和工厂模式
【设计模式学习】单例模式和工厂模式