Daniel Pitts wrote:
Stefan Ram wrote:
I have a class that is intended for subclassing,
not for instantiation.
So I thought, I could tag it with ?abstract?, even though it
does not have any abstract method.
Is this a good idea? Can human readers understand this
application of ?abstract??
Here is the concrete example:
abstract class MainCommand extends
de.dclj.ram.DefaultDirectedMessage { public MainCommand( final int
direction ){ super( direction ); } @java.lang.Override public
java.lang.String description(){ return "MainCommand"; }}
class QuitMainCommand extends MainCommand { public
QuitMainCommand(
final int direction ){ super( direction ); }}
?abstract? is foremost a kind of comment, intended
for human readers of the source code, here.
Yes, but often times it is a sign of a design flaw. What does this
hierarchy give you that doesn't involve implementing methods
differently? You shouldn't have to use instanceof or .getClass()
in
order to handle the subclasses in a useful way.
One typical case where I'd expect to see an abstract base class with
no abstract methods is if we have a family of similar classes where
a
subset of methods are identical in implementation. But the base
class
itself is uninteresting, so is not to be instantiated. Each subclass
adds further method implementations that result in sensible class
definitions.
In JPA this case can happen a lot, where all (or most entities) have
some common fields. Those common fields, hence their getters and
setters, can be placed in a single @MappedSuperclass, which is
declared abstract. Other common methods that can go here are
implementations of entity lifecycle callbacks.
Similarly junit.framework.TestCase. It's abstract because it would be
anything), but it has no abstract methods. If course, it's a special
convention, and these methods are found by reflection.