Note that there are some explanatory texts on larger screens.

plurals
  1. POA more generic visitor pattern
    primarykey
    data
    text
    <p>I'm sorry if my question is so long and technical but I think it's so important other people will be interested about it</p> <p>I was looking for a way to separate clearly some softwares internals from their representation in c++</p> <p>I have a generic parameter class (to be later stored in a container) that can contain any kind of value with the the boost::any class</p> <p>I have a base class (roughly) of this kind (of course there is more stuff)</p> <pre><code>class Parameter { public: Parameter() template typename&lt;T&gt; T GetValue() const { return any_cast&lt;T&gt;( _value ); } template typename&lt;T&gt; void SetValue(const T&amp; value) { _value = value; } string GetValueAsString() const = 0; void SetValueFromString(const string&amp; str) const = 0; private: boost::any _value; } </code></pre> <p>There are two levels of derived classes: The first level defines the type and the conversion to/from string (for example ParameterInt or ParameterString) The second level defines the behaviour and the real creators (for example deriving ParameterAnyInt and ParameterLimitedInt from ParameterInt or ParameterFilename from GenericString)</p> <p>Depending on the real type I would like to add external function or classes that operates depending on the specific parameter type without adding virtual methods to the base class and without doing strange casts</p> <p>For example I would like to create the proper gui controls depending on parameter types:</p> <pre><code>Widget* CreateWidget(const Parameter&amp; p) </code></pre> <p>Of course I cannot understand real Parameter type from this unless I use RTTI or implement it my self (with enum and switch case), but this is not the right OOP design solution, you know.</p> <p>The classical solution is the Visitor design pattern <a href="http://en.wikipedia.org/wiki/Visitor_pattern" rel="nofollow noreferrer">http://en.wikipedia.org/wiki/Visitor_pattern</a></p> <p>The problem with this pattern is that I have to know in advance which derived types will be implemented, so (putting together what is written in wikipedia and my code) we'll have sort of: </p> <pre><code>struct Visitor { virtual void visit(ParameterLimitedInt&amp; wheel) = 0; virtual void visit(ParameterAnyInt&amp; engine) = 0; virtual void visit(ParameterFilename&amp; body) = 0; }; </code></pre> <p>Is there any solution to obtain this behaviour in any other way without need to know in advance all the concrete types and without deriving the original visitor?</p> <hr> <p><strong>Edit:</strong> <a href="https://stackoverflow.com/q/31913">Dr. Pizza's solution seems the closest to what I was thinking</a>, but the problem is still the same and the method is actually relying on dynamic_cast, that I was trying to avoid as a kind of (even if weak) RTTI method</p> <p>Maybe it is better to think to some solution without even citing the visitor Pattern and clean our mind. The purpose is just having the function such:</p> <pre><code>Widget* CreateWidget(const Parameter&amp; p) </code></pre> <p>behave differently for each "concrete" parameter without losing info on its type </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload