Question

If I have an abstract class and derived classes of that class, am I correct that, according to good and practical design practice, that the derived classes should not provide extra public methods (they should only implement abstract classes and optionally override parent methods)?

Furthermore, is it acceptable practice to have a different constructor method signature for each derived class?

Answer 1

Personally, I see no problem with either.

As for extra public methods on derived classes:

There is limited usefulness in this, in many cases. The extra methods will not be usable when the class has been cast or set to an reference to the base class, which severely limits usefulness of this practice. That being said, there isn’t anything particularly wrong with this approach. Subclasses are meant to add specific behavior – sometimes, in a class hierarchy, there is new behavior in a subclass that isn’t appropriate for the base class. If the subclass is going to be used frequently on its own, it seems perfectly reasonable for the extra behavior to be modeled in the methods.

As for constructor signatures –

I see no problem with this either. Subclasses often need more information to be put into a usable state than the abstract class. That being said, I typically make sure to implement every constructor in the base class, plus add the new parameters required for the subclass.

That being said:

Unless there is good reason, I’d avoid having a subclass constructor with fewer parameters than the base class … why would I be able to specify something on a more generic case and not the specific case? I find that it’s usually confusing when subclasses have completely different construction options than their base classes.