Single-serving visitor pattern

In computer programming, the single-serving visitor pattern is a design pattern. Its intent is to optimise the implementation of a visitor that is allocated, used only once, and then deleted (which is the case of most visitors).

Applicability

The single-serving visitor pattern should be used when visitors do not need to remain in memory. This is often the case when visiting a hierarchy of objects (such as when the visitor pattern is used together with the composite pattern) to perform a single task on it, for example counting the number of cameras in a 3D scene.

The regular visitor pattern should be used when the visitor must remain in memory. This occurs when the visitor is configured with a number of parameters that must be kept in memory for a later use of the visitor (for example, for storing the rendering options of a 3D scene renderer).

However, if there should be only one instance of such a visitor in a whole program, it can be a good idea to implement it both as a single-serving visitor and as a singleton. In doing so, it is ensured that the single-serving visitor can be called later with its parameters unchanged (in this particular case "single-serving visitor" is an abuse of language since the visitor can be used several times).

Usage examples

The single-serving visitor is called through the intermediate of static methods.

Without parameters, this is SingleServingVisitor::applyTo(e);, while with parameters, it is SingleServingVisitor::applyTo(e, a, b);.

If implemented as a singleton:

SingleServingVisitor::setA(a);
SingleServingVisitor::setB(b);
SingleServingVisitor::applyTo(e);

Consequences

Pros

• No "zombie" objects. With a single-serving visitor, it is ensured that visitors are allocated when needed and destroyed once useless.
• A simpler interface than visitor. The visitor is created, used and free by the sole call of the applyTo() static method.

Cons

• Repeated allocation. At each call of the applyTo() method, a single-serving visitor is created then discarded, which is time-consuming. In contrast, the singleton only performs one allocation.

Implementation

Basic implementation (without parameters)

template <typename A, typename B>
class SingleServingVisitor {
protected:
    SingleServingVisitor() = default;
public:
    ~SingleServingVisitor() = default;

    static void applyTo(Element& e) {
        e.accept(SingleServingVisitor<A, B>());
    }

    virtual void visitA(A& a) = 0;
    virtual void visitB(B& b) = 0;
};

Passing parameters

If the single-serving visitor has to be initialised, the parameters have to be passed through the static method:

static void applyTo(Element& elem, const A& a, const B& b)  {
    elem.accept(SingleServingVisitor<A, B>(a, b));
}

Implementation as a singleton

This implementation ensures:

• that there is at most one instance of the single-serving visitor
• that the visitor can be accessed later

template <typename A, typename B>
class SingleServingVisitor {
protected:
    A a;
    B b;

    SingleServingVisitor() = default;

    // Note: instance() method need not to be public
    static SingleServingVisitor& instance() noexcept {
        static SingleServingVisitor ssv;
        return ssv;
    }
public:
    ~SingleServingVisitor() = default;

    static void applyTo(Element& e) noexcept {
        e.accept(instance());
    }

    // static methods to access parameters
    static void setA(const A& a) noexcept {
        this->a = a;
    }

    static void setB(const B& b) noexcept {
        this->b = b;
    }

    virtual void visitA(A& a) = 0;
    virtual void visitB(B& b) = 0;
};

Related patterns

• Visitor pattern, from which this pattern derives
• Composite pattern: single-serving visitor is often applied to hierarchies of elements
• Singleton pattern