Morgan Schweers wrote:
> For instance, just looking at the JavaDoc for TreeMap on Sun's site
> tells me that there are no 'protected' members, so I couldn't
> straightforwardly extend TreeMap with my own implementation for only a
> few key functions, I'd have to rewrite the important parts (any tree
> rotations, insertion/deletion details, etc.) nearly entirely myself. Is
> it necessary, for the specification, to carry over this practice? Is it
> a cleanliness/abstraction issue? While the source IS available with
> Classpath to modify freely, I feel it'd still be nicer to be able to
> derive, rather than copy and modify.
Yes, but the you
a) loose portability of such extended class - it will not work with sun
JDK, nor kaffe lib, nor any other lib
b) are not longer 'compatible' as defined by sun
c) are dependent on very special version of classpath - maybe in future
some internal implementation will change, breaking your class; by making
it all private, it is possible to keep promises on all interfaces,
without being pinned to single solution
As you said source is available. If you want to have very different
implementation, copy/paste it, conform to Collection interfaces and hack
on the code as you like. If you are going to do a big change, most code
will change anyway.
I know that it doesn't sound very OO-wise, but extending classes is not
for changing implementation details - at least not from the point of
solid subclass. At the point where class has defined all storage etc, it
is a bit too late to change it by inheritance.
Artur
