April 10, 2005
Meet the parents
Should a class be able to disavowe parts of its ancestry?
Assume an arrayish class Playlist. To quickly implement the List interface you might inherit from ArrayList:
class Playlist extends ArrayList
But now everyone can see that Playlist is an ArrayList when all you wanted to admit to is implementing List! Weirdos might cast Playlists into AbstractCollections! People might stuff Playlists into methods working on ArrayLists! Blood will be shed! Chaos will ensue!
So how about something like this instead:
class Playlist extends ArrayList concedes List
I understand one could deny Playlist's ancestry by wrapping an ArrayList in two pages of code, or trust the wisdom of my development team to shun concretely typed instances when possible. But that's not the point. Where Playlist's implementation magic comes from should be a secret between javac and myself. Hiding the ancestry of your classes seems no different than hiding the way they tick inside and my language should assist me in expressing this easily. When you're trying develop a future-proofish API that is going to get a lot of public exposure this detail begins to matter.
What do you think?
Comments
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)
