【设计模式】——访问者模式（Visitor Pattern）

目录

引言

一、访问者模式的基本概念

核心思想

访问者模式结构

UML图

应用场景

二、访问者模式的优点与缺点

优点

缺点

三、C++实现访问者模式

定义接口和类

客户端代码

输出结果

四、总结

---

引言

在软件工程中，设计模式是解决问题的一种常用方法，它们提供了可复用的解决方案，以应对常见的软件设计问题。访问者模式（Visitor Pattern）是一种行为型设计模式，用于在不改变现有对象结构的情况下，定义对对象结构中各个元素的访问操作。本文将详细探讨访问者模式在C++中的应用，并通过示例代码进行说明。

一、访问者模式的基本概念

核心思想

访问者模式的核心思想是将作用于数据结构中的各个元素的操作分离出来，封装成独立的类（访问者），使得在不改变数据结构的前提下可以添加作用于这些元素的新的操作。这种模式实现了数据结构与操作之间的解耦，提高了系统的灵活性和可扩展性。

访问者模式结构

访问者模式主要包含以下几个角色：

• 访问者（Visitor）：抽象访问者角色，为数据结构中的每个具体元素类声明一个访问操作。它通常是一个接口或抽象类，定义了访问每个具体元素的方法。
• 具体访问者（Concrete Visitor）：实现了抽象访问者所声明的接口，即具体定义了访问每个元素类的操作。
• 元素（Element）：抽象元素角色，定义了一个接受操作，即接受一个访问者对象作为参数的方法（通常是accept方法）。它也是一个接口或抽象类。
• 具体元素（Concrete Element）：实现了抽象元素所规定的接受操作，即实现了accept方法，并在该方法中调用访问者的访问方法以便完成对一个元素的操作。
• 对象结构（Object Structure）：这是一个包含多个具体元素角色的容器类，通常用来存储和管理元素对象，并提供遍历其内部元素的方法，使得访问者可以访问其内部的每个元素。

UML图

应用场景

访问者模式适用于以下场景：

1. 一个对象结构中包含多个类型的对象：希望对这些对象实施一些依赖其具体类型的操作。
2. 需要对一个对象结构中的对象进行很多不同的并且不相关的操作：这些操作应该被封装在访问者中，以避免“污染”元素类的代码。
3. 对象结构中对象对应的类很少改变，但经常需要在此对象结构上定义新的操作：使用访问者模式可以在不修改对象结构类的情况下增加新的操作。

二、访问者模式的优点与缺点

优点

1. 扩展性好：能够在不修改对象结构中的元素的情况下，为对象结构中的元素添加新的功能。
2. 复用性好：可以通过访问者来定义整个对象结构通用的功能，从而提高系统的复用程度。
3. 灵活性好：访问者模式将数据结构与作用于结构上的操作解耦，使得操作集合可以相对自由地演化而不影响系统的数据结构。
4. 符合单一职责原则：访问者模式把相关的行为封装在一起，构成一个访问者，使每一个访问者的功能都比较单一。

缺点

1. 具体元素对访问者公布了细节：这违反了迪米特法则（Law of Demeter），即一个对象应该对其他对象有尽可能少的了解。
2. 具体元素变更困难：如果具体元素类发生了变化（如增加了新的成员变量），那么可能需要修改所有相关的访问者类，这增加了维护的复杂性。
3. 违背了依赖倒置原则：访问者依赖的是具体的元素，而不是元素的抽象接口，这在一定程度上限制了系统的灵活性和可扩展性。

三、C++实现访问者模式

以下是一个使用C++实现的访问者模式示例，假设我们有一个汽车市场，包含不同类型的汽车（电动汽车、油电混动汽车、传统油车），我们想要对这些汽车执行不同的操作，如比较燃油需求、续航里程和价格。

定义接口和类

首先，我们定义汽车（Car）的接口和具体实现，以及访问者的接口和具体实现。

#include <iostream>  
#include <list>  
#include <memory>  
  
// 抽象元素 - 汽车接口  
class Car {  
public:  
    virtual void accept(class Visitor& visitor) = 0;  
    virtual ~Car() = default;  
};  
  
// 具体元素 - 电动汽车  
class ElectroCar : public Car {  
public:  
    void accept(Visitor& visitor) override {  
        visitor.visit(this);  
    }  
};  
  
// 具体元素 - 油电混动汽车  
class HybridCar : public Car {  
public:  
    void accept(Visitor& visitor) override {  
        visitor.visit(this);  
    }  
};  
  
// 具体元素 - 传统油车  
class OilCar : public Car {  
public:  
    void accept(Visitor& visitor) override {  
        visitor.visit(this);  
    }  
};  
  
// 抽象访问者  
class Visitor {  
public:  
    virtual void visit(ElectroCar& electroCar) = 0;  
    virtual void visit(HybridCar& hybridCar) = 0;  
    virtual void visit(OilCar& oilCar) = 0;  
    virtual ~Visitor() = default;  
};  
  
// 具体访问者 - 燃油需求  
class FuelVisitor : public Visitor {  
public:  
    void visit(ElectroCar& electroCar) override {  
        std::cout << "电车不需要燃油, 只要充电" << std::endl;  
    }  
  
    void visit(HybridCar& hybridCar) override {  
        std::cout << "混动车需要充电, 也需要燃油, 但相较于油车减少了燃油" << std::endl;  
    }  
  
    void visit(OilCar& oilCar) override {  
        std::cout << "燃油车需要燃油" << std::endl;  
    }  
};  
  
// 对象结构 - 汽车市场  
class CarMarket {  
private:  
    std::list<std::shared_ptr<Car>> cars;  
  
public:  
    void addCar(std::shared_ptr<Car> car) {  
        cars.push_back(car);  
    }  
  
    void accept(Visitor& visitor) {  
        for (auto& car : cars) {  
            car->accept(visitor);  
        }  
    }  
};

客户端代码

现在，我们可以在客户端代码中创建不同类型的汽车和访问者，并执行操作。

int main() {  
    CarMarket market;  
    market.addCar(std::make_shared<ElectroCar>());  
    market.addCar(std::make_shared<HybridCar>());  
    market.addCar(std::make_shared<OilCar>());  
  
    FuelVisitor fuelVisitor;  
    market.accept(fuelVisitor);  
  
    return 0;  
}

输出结果

电车不需要燃油, 只要充电  
混动车需要充电, 也需要燃油, 但相较于油车减少了燃油  
燃油车需要燃油

四、总结

访问者模式是一种强大的设计模式，它通过分离对象结构与操作，提供了高度的灵活性和可扩展性。然而，它也有其局限性，特别是在处理复杂对象结构和需要高性能的应用场景中。在决定使用访问者模式之前，需要仔细评估其优缺点，并考虑是否有更合适的替代方案。

在实际项目中，访问者模式常用于需要对一个复杂的对象结构（如树、图等）进行多种不同操作，且这些操作在将来可能会发生变化或增加的场景中。通过使用访问者模式，我们可以使得对象结构和操作之间保持独立，从而更容易地维护和扩展系统。