Question

I sometimes end up with a class hierarchy where I have an abstract base class with some common functionality and a couple of implementing classes that fall into two (rarely more) groups which I want to treat differently in some cases. An example would be an abstract tree node class and different branch and leaf implementations where I want to distinguish branches and leaves at some point.

These intermediate classes are then only used for “is-a” statements in flow control and they don’t contain any code, although I have had cases where they “grew” some code later.

Does that seem smelly to you? In my tree example, one alternative would be to add isLeaf() / isBranch() abstract methods to the base class and implement those on the intermediate classes, but that didn’t seem to be any better to me, really, unless I’d mean to have classes that could be multiple things at once.

Answer 1

In general, empty classes are a code smell.

I agree your isLeaf or isBranch methods are a correct alternative.
They add information about the objects , which is helpful.
(This is because, on the super class, you can’t express that subclasses are “either leaf or branch”).

---

The two methods with opposite results might also be considered as code duplication.

You could use only one… But I would recommend return an enumerated value LEAF or BRANCH.