Abstract class - Revision history

JaroslavTulach at 14:19, 28 April 2014

JaroslavTulach — Mon, 28 Apr 2014 14:19:23 GMT

←Older revision		Revision as of 14:19, 28 April 2014
Line 11:		Line 11:

	[[Category:APIDesignPatterns:Anti]]		[[Category:APIDesignPatterns:Anti]]
		+	[[Category:APIDesignPatterns]]

JaroslavTulach at 19:39, 12 May 2012

JaroslavTulach — Sat, 12 May 2012 19:39:57 GMT

←Older revision		Revision as of 19:39, 12 May 2012
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]].

JaroslavTulach: 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...

JaroslavTulach — Sat, 12 May 2012 19:35:52 GMT

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...

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 [[ClarityOfAccessModifiers]] is not obeyed, one can get into significant troubles as illustrated on the [[AlternativeBehaviour|factorial example]].

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]].

Also one can keep [[ClarityOfAccessModifiers]] even in [[abstract class]]es as for example {{JDK|java/nio/charset|CharsetEncoder}} shows by having all [[ClientAPI]] methods '''public final''' and all the others ''protected''.

Still, in the name of [[ClarityOfTypes|clarity]], consider separating [[APIvsSPI]] into separate types.

[[Category:APIDesignPatterns:Anti]]