ImplementOnlyAbstractClass

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Current revision (21:14, 8 May 2012) (edit) (undo)
 
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 and delegation to other 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.

Personal tools
buy