Home/ Questions/Q 1068875
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T20:20:30+00:00

If you write an interface with a lot of methods, say IPerson , and

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0