I'm working on a project that uses inheritance several times. In all cases. the superclass is not instantiated, so I could make it abstract. Before doing making it abstract, I want to check on what is the 'common practice' here.
Is making the superclass abstract in this situation just documentation that the class is not instantiated? Or am I creating an expectation in a subsequent developer that I have some specific design reason for not instantiating it?
In my case, there is no special reason for this design, it just turns out that every subclass needed to add its own methods, so the superclass is never instantiated as such.
TIA for any advice on what is 'good practice' here.
Joined: Jan 14, 2007
If there's no reason to make the class abstract then don't make it abstract. You're more likely to get so far down the line and end up making it instantiable again later when you finally need to. My philosophy on how to create code is generally an agile approach -- if you can't explain why (by unit tests or other means) you're complicating an interface, then don't complicate it. If you could provide an test case which showed a problem with drectly instantiating the class then you'd have reason to change your code
I only use abstract classes when:
a) I want to provide an interface along with some partial functionality b) I want to create a class that must never be instantiated directly
It sounds like you aren't doing either of those so your code should stay as it is
EDIT | Typo.. [ September 02, 2007: Message edited by: Chris Corbyn ]
Joined: Jan 29, 2003
Andrew, welcome to the ranch!
I'd vote the other way: use the most abstract thing you can. Prefer interface, abstract class, concrete class in that order. The infamous Extends is Evil article shows the dangers of extending a concrete class. Even if you don't buy everything he says, take away the risks of extending a concrete class and avoid it where possible. If you never do it, you will keep to the Liskov Substitution Principle much more easily.
BTW: If you're into topics like this, scroll on down to the OO, UML, etc. forum. This kind of conversation goes on all the time. [ September 02, 2007: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi