Storing a Type for Later Use
As I've already noted, the result of the typeid operator cannot be used for a dynamic_cast; for instance, the result of the typeid operator cannot be used for much of anything. It is therefore typically useless, and is certainly useless in the context we're working in here.
In the context of the Munchausen Pattern, the solution involved a type-list, which was possible because the types to be supported in the the Munchausen Pattern are known aforehand. That is not the case here, which means a type-list is not really an option.
While the type of the visitor is partially needed in the context of the adapter introduced above, it would be a very meager design choice to use an adapter For instance, our Task class will need to use the visitor independantly from the data-batch to extract information from it and, eventually, but outside the scope of this article, pass that information to another object. The most straightforward way to do this is, once more, to use an adapter which will, in this case, not store a pointer to an object of type VisitorType.
A skeleton of such a visitor adapter would look like this:
struct VisitorAdapter
{
virtual ~VisitorAdapter();
};
namespace Details
{
template < typename VisitorType >
struct VisitorAdapter : public ::VisitorAdapter
{
};
}
to which the necessary functions can be added as needed.
An In-depth Look at this Adapter Pattern
The original Adapter pattern[6] is summarized, by its authors, as follows:
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
The implementation as proposed in its original form is quite different from what I present here, however, in that in its original form, the adapter is derived from the adaptee and exposes an interface defined for the adapter, while calling functions on the adaptee accordingly. This means that common implementations of the Adapter pattern impose writing a new, independant, class for each class to be adapted and, worse in our case, tightly coupling that class with the class to be adapted[7].
The Adapter pattern I present here is the same pattern and serves the same purpose, but the implementation as presented here requires only the unification of the interface as a set of traits classes (which could be very much smaller than the number of classes to adapt) and a single, templatized, derived class which is specialized with the type to adapt.
