当前位置： 代码迷 >> 综合 >> 访问者(Visitor)模式
  详细解决方案

访问者(Visitor)模式

热度：45   发布时间：2023-12-24 10:16:34.0

访问者(Visitor)模式

隶属类别——对象行为型模式

1. 意图

?表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

2. 别名

无

3. 动机

考虑一个编译器，它将源程序表示为一个抽象的语法树。该编译器需在抽象语法树上实施某些操作以进行“静态语义”分析，例如检查是否所有的变量都已经被定义了。它也需要生成代码。因此它可能要定义许多操纵以进行类型检查、代码优化、流程分析，检查变量是否在使用前被赋初值，等等。还可使用抽象语法树进行优美格式打印、程序重构、code instrumentation已以及对程序进行多种度量。

这些操作大多数要求对不同的结点进行不同的处理，例如对代表赋值语句的结点的处理就不同于对代表变量或者算术表达式的结点的处理。因此有用于赋值语句的类，有用于变量访问的类，还有用于算术表达式的类，等等。结点类的语言的集合当然依赖于被编译的语言，但对于一个给定的语言其变化不大。

在这里插入图片描述

上面的类图显示了Node层次的一部分。这里的问题是，将所有这些操作分散到各种节点类中会导致整个系统难以理解、难以维护和修改。将类型检查代码与优美格式打印代码或流程分析代码放在一起，将产生混乱。此外，增加新的操作通常需要通常需要重新编译所有这些类。如果可以独立地增加新的操作。并且使这些节点类独立于作用于其上的操作，将会更好一些。

要实现上述两个目标，我们可以将每一个类中相关的操作包装在一个独立的对象(称为一个Visitor)中，并在遍历抽象语法树时将此对象传递给当前访问的元素。当一个元素“接受”该访问者是，该元素向访问者发送一个包含自身类信息的请求。该请求同时也将该元素本身作为一个参数。然后访问者将为该元素执行该操作——这一操作以前是该元素的类中的。

例如，一个不使用访问者的编译器可能会通过在它的抽象语法树种调用typeCheck操作对一个过程进行类型检查。每一个结点将对调用它的成员的typeCheck以实现自身的typeCheck()。如果该编译器使用访问者对一个过程进行类型检查，那么它将会创建一个TypeCheckingVisitor对象，并以这个对象为一个参数在抽象语法树上调用Accept操作。每一个结点在实现Accept时将回回调访问者：一个赋值结点调用访问者的VisitAssignment操作，而一个变量引用将调用VisitorVaribleReference。以前类AssignmentNode的TypeCheck操作现在成为TypeCheckingVisitor的VisitAssignment操作。

为使访问者不仅仅只做类型检查，我们需要所有的抽象语法树的访问者有一个抽象的父类NodeVisitor。NodeVisitor必须为每一个结点类定义一个操作。一个需要计算程序度量的引用将定义NodeVisitor的新的子类，并且将不再需要在结点类中增加与特定于应用相关的代码。

Visitor模式将每一个编译步骤的操作封装在一个与该步骤相关的Visitor中。
在这里插入图片描述
使用Visitor模式，必须定义两个类层次：一个对应于接受操作的元素(Node层次)另一个对应于定义对元素的操作的访问者(NoteVisitor层次)。给访问者类层次增加一个新的子类即可创建一个新的操作。只要该编译器接受的语法不改变(即不需要增加新的Node子类)，我们就可以简单的定义新的NodeVisitor子类以增加新的功能。

4. 适用性

在下列情况使用Visitor模式：

  • 一个对象结构包括很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。

  • 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Visitor使得你可以将相关的操作集中起来定义在一个类中。

    当该对象结构被很多应用共享是，用Visitor模式让每个应用仅包含需要用到的操作。

  • 定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作比较好。

5. 结构

在这里插入图片描述

6. 参与者

  • Visitor(访问者，如NodeVisitor)
    • 为该对象结构中ConcreteElement每一个类声明一个Visit操作。该操作的名字和特征标识了发送Visit请求给该访问者的那个类。这使得访问者可以确定正被访问元素的具体的类。这样访问者就可以通过该元素的特定接口直接访问它。
  • ConcreteVisitor(具体访问者，如TypeCheckingVisitor)
    • 实现每个由Visitor声明的操作。每个操作实现本算法的一部分，而该算法片段乃是对应于结构中对象的类。ConcreteVisitor为该算法提供了上下文并存储它的局部状态。这一状态常常在遍历该结构的过程中累积结果。
  • Element(元素，如Node)
    • 定义一个accept操作，它以一个访问者为参数。
  • ConcreteElement(具体元素，如AssignmentNode, VariableRefNode)
    • 实现accept操作，该操作以一个访问者为参数。
  • ObjectStructure(对象结构，如Program)
    • 能枚举它的元素
    • 可以提供一个高层的接口以允许访问者访问它的元素。
    • 可以是一个组合或者使用一个集合，如一个列表或一个无序集合。

7. 协作

  • 一个使用Visitor模式的客户必须创建一个ConcreteVisitor对象，然后遍历该对象结构，并用该访问者访问每一个元素。

  • 当一个元素被访问时，它调用对应于它的类的Visitor的操作，如果必要的话，该元素将自身作为这个操作的一个参数以便访问者访问它的状态。

    下面的SequenceDiagram说了一个对象结构，一个访问者和两个元素之间的协作。

在这里插入图片描述

8. 效果

访问者模式的优点：

    1. 访问者模式使得易于增加新的操作 访问者使得增加依赖于复杂对象结构的构件的操作变得容易了。仅需增加一个新的访问者即可在一个对象结构上定义一个新的操作。相反，如果每个功能都分散在多个类之上的话，定义新的操作时必须修改每一类。
    1. 访问者集中相关的操作而分离无关的操作 相关的行为不是分布在定义该对象结构的各个类上，而是集中在一个访问者中。无关行为却被分别放在它们各自的访问者子类中。这就既简化了这些元素的类，也简化了在这些访问者中定义的算法。所有与它的算法相关的数据结构都可以被隐藏在放在访问者中。
    1. 通过类层次进行访问 一个迭代器可以通过调用节点对象的特定操作来遍历整个对象结构，同时访问这些对象。但是迭代器不能对具有不同元素类型结构进行操作。

    这就意味着所有该迭代器能够访问的元素都有一个共同的父类Item。

    访问者没有这种限制。它可以访问不具有相同父类的对象。可以对一个Visitor接口增加任何类型的对象。例如,

    public interface Visitor {
      void visitMyType(MyType type);void visitYourType(YourType yourType);
}

    中，MyType和YourType可以完全无关，它们不必继承相同的父类。

缺点：

    1. 增加新的ConcreteElement类很困难 Visitor模式使得难以增加新的Elements的子类。每添加一个新的ConcreteElement都要在Visitor中添加一个新的抽象操作，并在每一个ConcreteVisitor实现相应的操作。有时可以在Visitor中提供一个缺省的实现，这一实现可以被大多数的ConcreteVisitor继承，但这与其说是一个规律还不如说是一个例外。

    所以在应用访问者模式考虑关键的问题是系统的哪个部分经常变化，是作用于对象结构上的算法呢还是构成该结构的各个对象的类。如果老是有新的ConcreteElement类加入进来的话，Visitor类层次将变得难以维护。在这种情况下，直接构成该结构的类中定义这些操作可能更容易一些。如果Element类层次时稳定的，而你不断地增加操作或修改算法，访问者模式可以帮助你管理这些改动。

  • 2）积累状态 当访问者访问对象结构中的每一个元素是，它可能会累积状态。如果没有访问者，这一状态将作为额外的参数传递给进行遍历的操作，或者定义为全局变量。

  • 3）破坏封装 访问者方法假定ConcreteElement接口的功能足够强，足以让访问者进行它们的工作。结果是，该模式常常迫使你提供访问元素内部状态的公共操作，，这可能会破坏它的封装性。

9. 实现

下面是应用Visitor模式时产生的其他的两种实现问题：

  • 1）双分派(Double-dispatch) 访问者模式允许你不改变类即可有效地增加其上的操作。为达到这一效果使用一种称为双分派(double-dispatch)的技术。这是一种很著名的技术，事实上，一些编程语言甚至直接支持这一技术(例如，CLOS).而像C++和Smalltalk这样的语言支持单分派(single-dispatch)。Java应该可以实现。

    在单分派语言中到底由哪一种操作将来实现取决于两个方面：该请求的名和接受者的类型。例如，一个GenerateCode请求将会调用的操作决定于你请求的结点对象的类型。在C++中，对一个VariableRefNode实例调用GenerateCode将调用VariableRefNode.GenerateCode(它生成一个变量引用的代码)。而对一个AssignmentNode调用GenerateCode将调用Assignment.GenerateCode(它生成一个赋值操作的代码)。所以最终哪个操作得到执行依赖于请求和接受者的类型两个方面。

    双分派意味着得到执行的操作决定于请求的种类和两个接受者的类型。accept是一个double-dispatch操作。它的含义决定了两个类型；Visitor的类型和Element的类型。双分派使得访问者可以对每一个类元的素请求不同的操作。

    这是Visitor模式的关键所在：得到执行的操作不仅决定于Visitor的类型还决定于它访问的Element的类型。可以不将操作静态地绑定在Element接口中，而将其安放在一个Visitor中，使用accept在运行时进行绑定。扩展Element接口就等于定义一个新的Visitor子类而不是多个新的Element子类。

  • 2）谁通常负责遍历对象结构 一个访问者必须访问这个对象结构的每一个元素。问题是，它怎么做？我们可以将遍历的责任放在下面三个地方中的任意一个:对象结构，访问者中，或者一个独立的迭代器对象中。

    通常有对象结构负责迭代。一个集合只需对它的元素进行迭代，并对每一个元素调用accept操作。而一个复合通常让accept操作遍历该元素的各子构件并对它们中的每一个递归地调用accept。

    另一个解决方案是使用一个迭代器来访问各个元素。在C++中，既可以使用内部迭代器也可以使用外部迭代器，到底用哪一个取决于哪一个可用和哪一个最有效。在Smalltalk中。通常使用一个内部迭代器，这个内部迭代器使用do:和一个块。因为内部迭代器由对象结构实现，使用一个内部迭代很大程度就像是让对象结构负责迭代。主要区别在于一个内部迭代器不会产生双分派——它将以该元素为一个参数调用访问者的一个操作而不是以访问者为参数调用元素的一个操作。不过，如果访问者的操作仅简单地调用该元素的操作而无需递归的话，使用一个内部迭代器的Visitor模式很容易使用。

    甚至可以将遍历算法放在访问者中，尽管这样将导致对每一个聚合ConcreteElement,在每一个ConcreteVisitor中都要复制遍历的代码。将该遍历策略放在访问者中的主要原因是想实现一个特别复杂的遍历，它依赖于该对象结构的操作结果。

10. 代码示例

首先是Element——ItemElement.java

public interface ItemElement {
    int accept(ShoppingCartVisitor visitor);
}

然后是对应的ConcreteElement——Fruit.java & Book.java

Fruit.java

public class Fruit implements ItemElement {
    private int pricePerKg;private int weight;private String name;public Fruit(int pricePerKg, int weight, String name) {
    this.pricePerKg = pricePerKg;this.weight = weight;this.name = name;}@Overridepublic int accept(ShoppingCartVisitor visitor) {
    return visitor.visit(this);}public int getPricePerKg() {
    return pricePerKg;}public int getWeight() {
    return weight;}public String getName() {
    return name;}}

Book.java

public class Book implements ItemElement {
    private int price;private String isbnNumber; //科普，ISBN 国际标准书号public Book(int price, String isbn) {
    this.price = price;this.isbnNumber = isbn;}public int getPrice() {
    return price;}public String getIsbnNumber() {
    return isbnNumber;}@Overridepublic int accept(ShoppingCartVisitor visitor) {
    return visitor.visit(this);}	
}

接下来是Visitor——ShoppingCartVisitor.java

public interface ShoppingCartVisitor {
    int visit(Book book);int visit(Fruit fruit);}

然后是ConcreteVisitor——ShoppingCartVisitorImpl.java

public class ShoppingCartVisitorImpl implements ShoppingCartVisitor{
    @Overridepublic int visit(Book book) {
    int cost = 0;// apply 5$ discount if book price is greater than 50if (book.getPrice() > 50) {
    cost = book.getPrice() - 5 ;} else cost = book.getPrice();System.out.println("Book ISBN: " + book.getIsbnNumber() + " cost = " + cost);return cost;}@Overridepublic int visit(Fruit fruit) {
    int cost = fruit.getPricePerKg() * fruit.getWeight() ;System.out.println(fruit.getName() + "cost = " + cost);return cost;}
}

最后是Client——ShoppingCartClient.java

// 符合好多原则啊 对修改关闭，对扩展开放 ，单一责任原则，将变化的和不变的分开，public class ShoppingCartClient {
    public static void main(String[] args) {
    // TODO Auto-generated method stubList<ItemElement> items = new ArrayList<>(Arrays.asList(new Book(50, "9527"), new Book(30, "9528"), new Fruit(30, 2, "Banana"), new Fruit(5,5,"Apple"))); int total = caculatePrice(items);System.out.println("Total cost = " + total);}static int caculatePrice(List<ItemElement> list) {
    ShoppingCartVisitor visitor = new ShoppingCartVisitorImpl();int sum = 0 ;for (ItemElement item : list) {
    sum += item.accept(visitor);}return sum;}}

以及对于的测试结果

Book ISBN: 9527 cost = 50
Book ISBN: 9528 cost = 30
Bananacost = 60
Applecost = 25
Total cost = 165

最后附上类的UML图（为了效果明显，我在生成类图时，把Visitor和Element的引用放到了域中）

在这里插入图片描述

11. 已知应用

Smalltalk-80编译器有一个称为ProgramNodeEnumeration的Visitor类。它主要用于那些分析源代码的算法。它未被用于代码生成和优美格式打印，尽管它可以做这些工作。

12. 相关模式

Composite: 访问者可以用于对一个由Composite模式定义的对象结构进行操作。

Interpreter:访问者可以用于解释。

13. 设计原则口袋

  • 封装变化
  • 针对接口编程，不针对实现编程
  • 依赖抽象，不依赖具体类
  • 为交互对象间的松耦合设计而努力
  • 多用组合，少用继承
  • 类应该对扩展开放，对修改关闭
  • 只有和密友聊天
  • 好莱坞原则——别来找我，我会来找你
  • 单一责任原则——类应该只有一个改变的理由

14. 参考文献

《设计模式：可复用面向对象软件的基础》

《HeadFirst设计模式》

  相关解决方案

代码迷 - 您身边的软件异常，代码异常，编程异常助手（发现，解决，分享）
Copyright © 2009-2013 DAIMAMI.COM. All rights reserved.