This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
That is a very good question. I shall give you one opinion about it
. . . an "is-a" relationship exists between the two classes.
. . .
There are a number of obvious violations of this principle in the Java platform libraries. For example, a stack is not a Vector, so Stack should not extend Vector. Similarly, a property list is not a hash table, so Properties should not extend Hashtable. In both cases, composition would have been preferable.
Patricia Samuel wrote:
Why do some classes in API extends HashTable?
There can't be many and if they do they're very old. This is because its a long time ago now that Hashtable was replaced by the HashMap as the preferred hash based Map.
Are you asking why classes still extend Hashtable and why they're not changed to extend HashMap instead? That's because once something is in the Java API it's almost impossible to change because that would potentially break existing code.
Joined: Sep 12, 2007
Hey Mr. Campbell,
I m sorry but i can't get the explanation you mentioned.
Shall i consider the thing what Embla said? Is it the only reason that some API extends Hashtable?
Think about the class "Properties". It is supposed to hold pairs of Strings. I have one String, the "key", and the Properties object can give me the other String, the "value". That sounds a lot like what Hashtable is supposed to do, except Hashtable does it with Objects. Someone decided -- and i think we can all agree, it was a bad decision -- to implement Properties by extending Hashtable and adding a few methods that cast Object to String, so you can say
String value = props.getProperty(key);
String value = (String) props.get(key);
If you were to design the Properties class today, it actually might make good sense to let it extend HashMap<String, String>, letting the language handle the type safety. Or alternatively, as people have already suggested, you could use composition instead.
As Ms Tingeling indicates, once a bad decision is made in the Java APIs, it lasts forever. Sun won't make a change that will stop existing code from compiling.
Now, regarding making the bad decision in the first place: people often forget that the oldest classes in the Java API (and that includes Hashtable, Properties, Stack, Vector, String, System, Math, Runtime, and many others) were written by people brand new to Java! That's obvious in retrospect, but you have to think about it first. These people came from their experience working in other languages, with other ways of doing things, notably Smalltalk and Scheme and to a lesser extend C++ (which at the time was often used with a popular class library called NIHCL, the NIH Class Library, which had a single-rooted inheritance hierarchy...) Anyway, the best practices for Java -- and for object-oriented programming in general -- have evolved a lot since the early nineties. It's easy to look back and say "that was a dumb idea!", but at the time, it was common practice. "Design Patterns" was published the year after the first public alpha of Java appeared.