making superclass abstract -- best practice

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.

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 ]

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 ]

Thanks for the thoughtful replies. Very helpful.

Chris: I am doing a) in your list of reasons for making a class abstract; so it seems you both would vote in favor of making the superclasses abstract.

Thanks also for the pointer to the OO, UML forum. I suspect I'll be hanging around there a fair bit, working on design issues such as this one.

Again, thank you!

I tend for the 1st approach: I there's really no reason to prevent instantiation, then I tend to allow it.

At least with domain objects, I really try to ask myself whether it makes sense to have such independent instances in the real world.
You know, like the oh-so-boring classical examples:
If's your going to manage employee entities in enough detail to have classes "Secretary", "Engineer", "HR manager", etc, then their superclass "Employee" might be abstract, on the simple grounds that when you get hold of actual 3-dimensional person, he'll never be "Just an Employee", he's bound to have a more specific job definition (well, usually....).

On the other hand, if by sheer luck I never got to instantiate a "Secretary" yet, but I believe a secretary is likely to come by in the future, then I'll make it concrete.

Of course, there are tons of exceptions to such rules (including technical reasons, or laziness of other programmers, which might force me to allow instantiation even of Employee... ).
So I would never presume to advise on an application I'm not familiar with... but that's just my default approach.

If you look at the source to the Java SE API classes, you'll see that they often define three things:

Interface defining minimum

abstract class defining some common functions and data elements (fields)

one or more concrete classes that implement the interface

While its really an engineering question, all about tradeoffs, by now the JDK classes have had nearly a decade of polish, so I consider them a decent style guide.

I feel that having to provide a default implementation that does nothing, like some of the listeners and event handlers in the library, is an admission of failure. I've given you an interface and it's so painful to implement for simple purposes that I have to also give you a default implementation. The interface might be a mess? I've done it but I felt dirty.

Much of the library cannot be "polished" because once an API is published Sun is pretty much stuck with it for life unless they're willing to burn all the developers like MS used to do now & then. Remember that much of it was written by Java newbies who had not seen any code written by anyone outside their team ... there was none. What if there had been more Smalltalkers among them and fewer C++ fans?

Originally posted by Stan James:
What if there had been more Smalltalkers among them and fewer C++ fans?

From your lips to God's ears.
I've gotten 'used to' the c-intrinsics, but never like them. Autoboxing helps, but they are still an evil kludge from when folks thought that people could write faster code than compilers.