DelegationAndComposition

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Line 3: Line 3:
While reuse by subclassing often leads to ''accidental reuse'' (as demonstrated in [[ClarityOfAccessModifiers]] essay). The delegation and composition is as powerful as subclassing, yet it implies ''reuse by design'' as one clearly needs to think about allowing composition - more about that for example in [[ClarityOfTypes]].
While reuse by subclassing often leads to ''accidental reuse'' (as demonstrated in [[ClarityOfAccessModifiers]] essay). The delegation and composition is as powerful as subclassing, yet it implies ''reuse by design'' as one clearly needs to think about allowing composition - more about that for example in [[ClarityOfTypes]].
-
:TBD: clear definition of version
+
[[TBD]] clear definition of version
-
:TBD: Separation of [[ClientAPI]] and [[ProviderAPI]]
+
[[TBD]] Separation of [[ClientAPI]] and [[ProviderAPI]]
-
:TBD: post/pre condition checks.
+
[[TBD]] post/pre condition checks.
-
:TBD: privileged mode and security
+
[[TBD]] privileged mode and security

Revision as of 08:08, 10 January 2011

Delegation and composition is one way to achieve code reuse. In classical object oriented languages it is sort of second class citizen, but that does not mean it is less powerful. Quite opposite.

While reuse by subclassing often leads to accidental reuse (as demonstrated in ClarityOfAccessModifiers essay). The delegation and composition is as powerful as subclassing, yet it implies reuse by design as one clearly needs to think about allowing composition - more about that for example in ClarityOfTypes.

TBD clear definition of version TBD Separation of ClientAPI and ProviderAPI TBD post/pre condition checks. TBD privileged mode and security

Personal tools
buy