ImplementOnlyAbstractClass
From APIDesign
(Difference between revisions)
(One intermediate revision not shown.) | |||
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 other hand, this prevents multiple inheritance for implementors. Whether to choose the [[ImplementOnlyAbstractClass]] or [[ImplementOnlyInterface]] is ultimately a matter of personal preference. | + | 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 and delegation from one implementor to other implementors. Whether to choose the [[ImplementOnlyAbstractClass]] or [[ImplementOnlyInterface]] is ultimately a matter of personal preference. |
[[Category:APIDesignPatterns]] | [[Category:APIDesignPatterns]] | ||
[[Category:APIDesignPatterns:Clarity]] | [[Category:APIDesignPatterns:Clarity]] | ||
[[Category:APIDesignPatterns:Creational]] | [[Category:APIDesignPatterns:Creational]] |
Current revision
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 and delegation from one implementor to other implementors. Whether to choose the ImplementOnlyAbstractClass or ImplementOnlyInterface is ultimately a matter of personal preference.