Home » Uncategorized

Extending Non-Abstract Classes

30 December 2003 1,955 Views No Comment

Many people create APIs that extends concrete (non-abstract) classes. I have come to avoid this practice. Through the use of design patterns (especially strategy) I have come up with much better designs. It is my preference that classes are either final or abstract. If they are final, nobody can extend them. If they are abstract, then all of their methods should be either final or abstract.

Why shouldn’t you extend a concrete class and override one of its methods? It breaks encapsulation. You have to know about the innards of the class that you are extending. Just because you have an IS-A relationship to another class doesn’t mean that you shouldn’t worry about encapsulation.

http://fishbowl.pastiche.org/2002/12/17/inheritance_taxonomy
http://www.manageability.org/blog/stuff/inheritance_revisited/view
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
http://research.microsoft.com/comapps/docs/Inherit.doc

Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.