Re: Define Type at runtime
BGB wrote:
Lew wrote:
BGB wrote:
Lew wrote:
BGB wrote:
John wrote:
If I have a method:
public void someMethod(Object o){
...
Entity<T> entity;
....
}
How could I define at runtime the type T if I have an Object?
....[snip] ...
and, probably, not to forget "instanceof".
That's pretty useless in this context.
<snip>
but, whatever works...
By which I assume you at least mean compiles.
'instanceof Entity<T>' will not compile.
where did I ever write "instanceof Entity<T>"?...
You suggested he use 'instanceof' to cast to type 'T' or, depending on what=
the OP meant, 'Entity<T>', since you suggested to use 'instanceof' in the =
OP's context. Didn't you intend to answer the OP's question, or were you a=
ttempting to provide information that didn't pertain to the question at han=
d?
If you intended to pertain to the question, then you were advising 'instanc=
eof' to check for a non-reifiable type.
the fact that it will not compile, on account of not being valid code,
is not the issue, because I never wrote that, or suggested that fragment=
as a valid solution...
if-then chains of type comparisons are a major antipattern, a point you =
gloss over. It means that you aren't using polymorphism and type-safe code=
.. It's a Bad Thing.
if (x instanceof Foo)
{
// do one thing
}
else if (x instanceof Bar)
{
// do another thing
}
else if (x instanceof Baz)
{
// OK, this code is far too stupid. Refactor intelligently.
}
...
You're supposed to have
Super foo = obtainASubtypeInstance();
foo.polymorphicMethod();
but, this only works assuming that some "Super" exists within the class=
heirarchy... what if it does not? what if the original objects in
question were never designed with this use case in mind? ...
Then you use overloads instead of overrides.
Either way, it's probably a case of bad design to have that much 'instanceo=
f' chaining - very much a non-O-O approach.
if it is just a big pile of unrelated objects (with neither a common
superclass nor a common interface) then instanceof will probably work...
More likely a refactoring would work better. Yes, it will "work", but it's=
brittle and shows that some analysis was not completed.
like, say:
if(obj instanceof Integer)
...
else if(obj instanceof String)
...
else if(obj instanceof JLabel)
...
The need for such is rare indeed, vanishingly rare. The usual and more mai=
ntainable approach is to use overloads. The problem with what you suggest =
is it pushes compile-time checking into run-time checking.
but, again, it is a big question of what is being done and why, which
was not addressed here.
Chance are, though, that what is being done and why is better served by doi=
ng things in a more typesafe fashion.
pattern vs antipattern vs ... isn't really an issue IMO, more just
You are correct, that is your opinion.
scare-tactics and prescriptivism (people don't like something or a way
of doing something, so they call it an antipattern...).
That's not what I'm doing.
the bigger question is when and why someone does something, not that
they have done it (at least, as far as programming goes).
Chance are that the OP's scenario is poorly served by 'instanceof' chains, =
particularly since they're trying to check on a non-reifiable type and 'ins=
tanceof' won't compile anyway.
You are correct that it depends on the use case, but very few use cases are=
best served by the 'instanceof' antipattern. All the ones I've seen in th=
e wild were examples of poor design.
--
Lew