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