Re: Visitor pattern vs if-ladder
Giovanni Azua wrote:
Not only annoying but also error-prone and pollutes the Element Model
hierarchy with unrelated concerns. But it does not have to be that way :]
e.g. there is no need for accept methods in the implementation below. The
elements are visit(ed) directly without accept roundtrips in order to
achieve the desired double-dispatch:
....
There are few cases where using reflection would actually be a good
idea. This is not on of those.
Several problems I see here:
1. You're not doing it right. If you're going to complain about the
visitor pattern being error-prone, the least you could do is to provide
a *correct* implementation.
2. Speed? Reflection is very slow and prohibits any kind of optimization
whatsoever.
3. Using reflection kills type safety, since you're essentially
prohibiting the compiler from figuring out what's going on. Another way
of putting it is that you've added dynamicism which pushes what should
be compile-time errors to runtime. Which is the wrong direction, in case
you didn't know.
Off the top of my head, I can think of only two reasons to use
reflection: either you have something akin to a scripting engine, or you
have a library that needs to be able to inspect running class methods
for various reasons.
The key thing is that reflection should be a tool of last resort, not a
cheap trick you use to get around laziness.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth