Re: The merits of dynamic_cast<>()
In article <16ab754c-e04f-4425-a8d5-
7ec695d9aa9a@e18g2000vbe.googlegroups.com>,
nick_keighley_nospam@hotmail.com says...
On 17 Sep, 09:44, James Kanze <james.ka...@gmail.com> wrote:
On Sep 16, 10:07 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
The problem is that too few people recognize the subclass
relationship in this manner. ?They view inheritance as an
opportunity for reuse or worse: the best or ONLY opportunity
for reuse. ?I was actually lectured by a supervisor one time
that the entire purpose of the inheritance relationship was
for reuse when I suggested separating some responsibilities.
Perhaps he was coming from Smalltalk (and an IMHO out of date
point of view concerning inheritance). ?In C++, we usually
distinguish two types of inheritance, interface and
implementation, with private inheritance being used for the
latter, and a realization that containment is usually
preferrable to inheritance for implementation. ?
what about abstract base classes? How do they fit in?
Suppose the OP had an abstact base class
class Drawable;
Then things like Circles, Rectangles, BezierBlobs etc.
all derive from Drawable. The container he's dynamic casting
is a container of Drawable*s. Are those concrete shapes violating
LSP? They do things in addition to the original base class
contract.
Do they? I find that drawables really don't differ very much. You
might have a hit test, a draw() function, extents() maybe...not much
else. At any rate whatever behavior you have in drawables is pretty
much universal in that they all implement the same thing in different
ways.
The way they differ is in the method you create them. This is why you
of course separate drawable from its creation.
Now, I do have a very similar problem in a real-world application I'm
working on. Not that these drawables have different behavior but that
they represent objects that are not "drawable". I have to put them into
a boost::graph structure. When the user selects one to edit I need to
provide unique edit interfaces for each.
Now, I don't like the idea of embedding the edit behavior in the object
and prefer not to have the object depend on the edit behavior at all.
In other words, the object that is editing X must not be known by X.
The reason for this is that the method of editing is more generally
going to be the thing that is changed or could have multiple methods.
So, I do need to be able to see what type I'm looking at and then supply
the appropriate editor. There's of course one direction you could take:
switch (selected_object.type())
{
case X:
cast to ?? and create editor....
case Y:
....
}
However, why do that when the RTTI does basically the same thing?
Furthermore, this switch can end up appearing in multiple places. Yet
further I may need to override the editor creation method.
Enter the visitor as described in _Modern C++_:
struct visitor { virtual ~visitor(); };
template < typename Visited >
struct visitor_base
{
virtual visit(Visited & v) = 0;
};
#define IMPLEMENT_ACCEPT(type) \
void accept(visitor & vis) \
{ \
if (visitor_base<type> * my_vis = \
dynamic_cast< visitor_base<type> * >(&vis)) \
{ \
my_vis->visit(*this); \
} \
}
struct visited_x
{
IMPLEMENT_ACCEPT(visited_x)
};
This puts the dynamic_cast<> into a cubby hole behind an abstraction. I
then build visitors like so:
struct count_x_and_y : visitor_base<x>, visitor_base<y>
{
int x_count, y_count;
count_x_and_y() : x_count(), y_count() {}
void visit(x & var) { ++x_count; }
void visit(y & var) { ++y_count; }
};
If I pass this into a pile of objects that contain x, y, and z objects
then it will count x and y but not z.
I do tend to try and avoid dynamic_cast all together but when you
honestly need something like this then I generally prefer to put it
behind some sort of abstraction. I've found this kind of thing works
fairly well though there have been some issues when it comes to unit
testing (visitors tend to be coupled to a lot of stuff).
And the end of the day you're simply going to have to balance all the
mutually exclusive principles you need to apply in order to accomplish
your goal. Each and every principle has a very good reason for
existing, it's just not generally possible to perfectly apply them all.