ImplementOnlyAbstractClass
From APIDesign
(Difference between revisions)
Line 10: | Line 10: | ||
</source> | </source> | ||
- | It is clear that these '''protected''' method cannot be called by anyone else except the [[API]] infrastructure. On the | + | It is clear that these '''protected''' method cannot be called by anyone else except the [[API]] infrastructure. On the other hand, this prevents multiple inheritance for implementors. Whether to choose the [[ImplementOnlyAbstractClass]] or [[ImplementOnlyInterface]] is ultimately a matter of personal preference. |
+ | |||
+ | [[Category:APIDesignPatterns]] | ||
[[Category:APIDesignPatterns:Clarity]] | [[Category:APIDesignPatterns:Clarity]] | ||
[[Category:APIDesignPatterns:Creational]] | [[Category:APIDesignPatterns:Creational]] | ||
- |
Revision as of 21:13, 8 May 2012
Safer variant to ImplementOnlyInterface is to use abstract class with protected methods. Then it is clear the meaning of such methods is clear again as advocated by ClarityOfAccessModifiers.
The NonMixedFactory.Provider interface would then become:
public abstract class Provider { protected abstract void initialize(Callback c); protected abstract int toBeImplementedBySubclass(); }
It is clear that these protected method cannot be called by anyone else except the API infrastructure. On the other hand, this prevents multiple inheritance for implementors. Whether to choose the ImplementOnlyAbstractClass or ImplementOnlyInterface is ultimately a matter of personal preference.