DelegationAndComposition - Revision history

JaroslavTulach at 08:09, 10 January 2011

2011-01-10T08:09:00Z

←Older revision		Revision as of 08:09, 10 January 2011
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

JaroslavTulach at 08:08, 10 January 2011

2011-01-10T08:08:38Z

←Older revision		Revision as of 08:08, 10 January 2011
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

JaroslavTulach at 09:38, 1 April 2009

2009-04-01T09:38:29Z

←Older revision		Revision as of 09:38, 1 April 2009
Line 6:		Line 6:
	: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

JaroslavTulach at 09:28, 1 April 2009

2009-04-01T09:28:26Z

←Older revision		Revision as of 09:28, 1 April 2009
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.

JaroslavTulach at 09:28, 1 April 2009

2009-04-01T09:28:11Z

←Older revision		Revision as of 09:28, 1 April 2009
Line 5:		Line 5:
	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.

JaroslavTulach: New page: 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 op...

2009-04-01T09:02:37Z

New page: 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 op...

New page

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