Abstract class

From APIDesign

An Abstract class in an API is suspicious. Often it just shows the API designer was not sure whether the goal is to create a ClientAPI or ProviderAPI. In case the ClarityOfAccessModifiers is not obeyed, one can get into significant troubles as illustrated on the factorial example.

Extending existing abstract class with new methods is not 100% compatible either. Binary compatibility is usually OK, but by adding new method one can break the source compatibility (method with the same name and signature could exist and be private in some subclass). One can also compromise the functional compatibility (method with same signature and name exists and is public - in such case it gets called in unpredictable moments).

Not all usages of abstract classes are bad. For example the ImplementOnlyAbstractClass benefits from richer set of access modifiers one can use in abstract classes than in ImplementOnlyInterface.

Also one can keep ClarityOfAccessModifiers even in abstract classes as for example CharsetEncoder shows by having all ClientAPI methods public final and all the others protected.

Still, in the name of clarity, consider separating APIvsSPI into separate types.