Re: Visitor pattern vs if-ladder
Philipp a ??crit :
I think about replacing an if-ladder (with instanceof calls) in my
code with a visitor pattern, but the advantages are not really obvious
to me.
....
I ran the counting with 8 types of vehicle on 10^8 randomly produced
vehicles 10 times alternatively (each run is ~16 sec, all 20 runs are
in one JVM execution, so warm up should be accounted for). The ladder
implementation is about 10% faster (mean time per run: ladder 16800ms,
visitor 18380).
I'm not saying that this is a big difference or should influence the
decision very much. It's just FYI.
Micro-benchmarks are notoriously unreliable. Aside from that, the real cost
isn't run time but maintainability of the source.
Albert wrote:
For such a simple case, why not using simple overriding ? You could add
a method Vehicle.count(int[]) with one implementation for each subclass
of Vehicle.
This answer points up that a question of the form, "Should I do A or B?" is
often less powerful than, "Is there an alternative to A?" It might well be
that neither A nor B is the best option.
In the OP's case, I wouldn't have gone with the visitor pattern either. I see
the alternative to an if-ladder as polymorphism nearly always.
With an if-ladder, you have to recode for every possible scenario. With
polymorphic subclass implementations, there are idioms available that let you
configure reflectively at run time what options you have, with no recoding
necessary. If-ladders tend to be long blocks of code, polymorphic invocations
just a few lines, even if you don't use a run time configuration option.
If-ladders require a supertype to have explicit knowledge of subtypes, a very
limiting restriction. The combination of polymorphism and a factory method
frees a client from any such constraint.
It's one of my rules of thumb that blocks of if-checks for 'instanceof' should
be replaced by a polymorphic invocation.
--
Lew