Submission: switch (...) instanceof feature

[Gabriel Belingueres]

> .. another different questions:
> - if strategies like this will be reasonable regarding footprint of whole
> application.

Do you mean memory footprint? You may implement those Strategies as
Singletons if you know they do not store any state, or even as a
Flyweights if the different instances are limited. I would keep it as
simple as possible.

> - readability of code for externals

IMO, readability is not important very important if the application
life cycle will be short. I would apply the KISS principle again.

> - isolating the instanceof code to *additional* unique method will not
> really solve the issue. In my case, the lookup method *is* the unique
> method.

If the lookup method is the only place you do the instanceof test,
then it seems reasonable to keep it that way, instead of creating all
that strategy pattern code.
However, I can not see how changing the instanceof by a switch
statement would improve the code, UNLESS the switch statement adds
some value, for example that it would perform far better than an
if-elseif-else chain AND do some checks, like throwing a compiler
error when I write something like this:

class A {}
class B extends A {}

...
switch(o) instanceof {
case A:
  // do something with this A instance
  break;
case B:
  // never enter this branch if it's a B because it is always catched by the
  // previous case
  break;
...
}