Naming of classes providing the complete implementation of an interface, but which are designed to be extended / used as mixins.

Question

If you write an interface with a lot of methods, say IPerson, and you expect a lot of different implementations of it, it is quite common practice to provide an abstract class AbstractPerson which implements the bulk of the functionality.

Normally AbstractPerson is abstract, since you usually leave some key functionality unimplemented. In this case the naming makes sense.

But what is a good naming convention in case you already implemented all of IPerson, but still expect subclasses? Perhaps PersonMixin, PersonHelper, GenericPerson or simply Person? I think Person is a bit vague, since it doesn't clearly show the intended usage.

Answer 1

I think Person is just fine. The whole point is that you might specialize it to specific types of people, but it's still a person.

Answer 2

If it can be used as-is, I'd stick with Person. If not, I'd make it abstract (even if it has no abstract members) and call it PersonBase.

Answer 3

Although this is from the Framework Design Guidelines (for .NET), I think it applies equally to any language. The reccomendation is:

Avoid naming bases class with the Base suffix if the class is intended to be used in public APIs. If the library exposes the base class as a return type or parameter type, it should not have the Base suffix.

In general, if the class is public (or even private, although there is less risk in that case) and you name it PersonBase there is an implication that it is a base class. If at some point in the future the class hierarchy is refactored and PersonBase is no longer the base class you would want to rename PersonBase to something else which would most likely result in a breaking change for any consumer code.

I would simply name the class Person and let any derived classes use more specific names. I think Person is very clear and indicative of it's use as a generic (non-specific) person.