Abstract class
From APIDesign
(New page: 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 [[Cla...) |
|||
| (One intermediate revision not shown.) | |||
| Line 1: | Line 1: | ||
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 [[AlternativeBehaviour|factorial example]]. | 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 [[AlternativeBehaviour|factorial example]]. | ||
| + | |||
| + | Extending existing [[abstract class]] with new methods is not 100% [[BackwardCompatibility|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 class]]es are bad. For example the [[ImplementOnlyAbstractClass]] benefits from richer set of access modifiers one can use in [[abstract class]]es than in [[ImplementOnlyInterface]]. | Not all usages of [[abstract class]]es are bad. For example the [[ImplementOnlyAbstractClass]] benefits from richer set of access modifiers one can use in [[abstract class]]es than in [[ImplementOnlyInterface]]. | ||
| Line 9: | Line 11: | ||
[[Category:APIDesignPatterns:Anti]] | [[Category:APIDesignPatterns:Anti]] | ||
| + | [[Category:APIDesignPatterns]] | ||
Current revision
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.
Follow
