Re: abstract static methods (again)
Andreas Leitgeb wrote:
Eric Sosman <Eric.Sosman@sun.com> wrote:
Andreas Leitgeb wrote:
I still see some merit in being able to enforce that any concrete
class implementing some thusly declared interface had to offer some
particular c'tor, as a means to help developers of such classes to
not forget about it.
Here's my objection: Suppose there's an Entertainer interface
(or abstract class) and ...
...
Okay, it might make sense for the class of Comedians to have a
default stale Joke (a faithful model of reality, perhaps), ...
:-)
...
The author of Entertainer, who knew nothing about the wants and needs
of those who would come later, ...
Thanks for the entertaining example, but I think it's beside the point.
This type of argument "it's bad for this exemplary usecase, so it must
be bad for all usecases" is obviously flawed. (or was a joke, itself)
"Bad for one, bad for all" -- Sounds like _Les Trois Mousquetaires_,
non? But the point of my (rather whimsical) illustration is that I
think "specialization" is the principal motivation for subclassing,
and that the situation I describe is not just one isolated oddity but
quite common.
The specialized subclass quite often has attributes not shared with
the superclass or interface, and those attributes are frequently modeled
by instance variables. If the instance variables need non-default
values for the instance to be "functional," a logical way to provide
those values is through the constructor. An external mandate that
requires a non-constructor route for initializing the values seems to
do little more than force the programmer to jump through unnecessary
hoops: Dream up defaults even when none suggest themselves, provide
setters (and give up `final'), throw IllegalStateException all over
the place ... All just so the @#$!*!! mandate can be satisfied.
On second thought: If the Entertainers were designed to be dynamically
loaded by name, then Comedians just wouldn't have any chance of a individual
default joke. They could offer their Joke- constructor, but unless they
also offered a no-args one, they just wouldn't ever be successfully engaged.
I'm not sure why the second sentence follows from the first: Once
you've got the Class object, you can surely use getConstructors() on
it, can you not? And if you know enough to be able to supply a Joke to
a post-construction setter, why couldn't you just as well hand it to
a Constructor's newInstance() method?
But I admit that my familiarity with frameworks of this kind is
slight. Perhaps they're just not suited for classes whose instances
lack obvious defaults. (Maybe they're only good for singletons?)
--
Eric.Sosman@sun.com