Could someone please explain when would I want to use delegation instead of inheritance?
+11
A:
When you want to "copy"/Expose the base class' API, you use inheritance. When you only want to "copy" functionality, use delegation.
One example of this: You want to create a Stack out of a List. Stack only has pop, push and peek. You shouldn't use inheritance given that you don't want push_back, push_front, removeAt, et al.-kind of functionality in a Stack.
Anzurio
2009-05-07 01:40:15
Good rule of thumb.
Frank V
2009-05-07 01:41:39
+7
A:
They have nothing to do with each other. Delegation is a behavior. Inheritance is a model technique.
Inheritance is for modeling "is-a". A computer "is-a" electronic system.
Delegation is how methods provide results. Sometimes one object will delegate work to another object. Delegation can be via any relationship -- you can delegate to a superclass, to a member of a composite or aggregate, or any relationship.
S.Lott
2009-05-07 01:41:57
Inheritance is for modeling "is-a" relationships but also where the sub class extends the functionality of the base class and does nothing to restrict it.
Velika
2009-05-07 03:46:02
@Chadworthington: Not true; a subclass can override methods and replace them -- essentially a restriction -- without delegating back to the superclass.
S.Lott
2009-05-07 10:38:41
@S.Lott: While you can override methods, you have to be careful to override all the methods that expose the behaviour you want to restrict - including some that may not have been written yet. @Chadworthington's advice is safer, particularly when you don't control the superclass.
Bill Michell
2009-05-11 11:12:56
So basically, it should be easy to determine when you want to delegate - the hard bit is to decide whether to do it via inheritance or not!
Casebash
2010-01-14 23:35:49
IMO it's an overstatement to claim "they have nothing to do with each other". It's often a difficult question whether to use "is a" rather than "has a" relationships when creating a model. Especially since all "is a" relationships can be modeled as "has a" relationships instead. The Go language doesn't even have classical inheritance relying entirely on delegation for code reuse.
KaptajnKold
2010-07-28 08:53:54
A:
You may use delegation to multiple internal class instances to simplify their functionality into a common grouping. If your language doesn't implement multiple inheritance for instance you may inherit from one of the bases and wrap the other, delegating the functionality you want to expose to the underlying implementation. Inheritance also ties your class into the hierarchy of classes you are inheriting from where as with delegation you may keep your place in your own hierarchy and delegate calls to another.
Adam Markowitz
2009-05-07 01:47:38
A:
Assume your class is called B and the derived/delegated to class is called A then
Here are some xamples when inheritance or delegation are being used:
If
- you want to express relationship (is-a) then you want to use inheritance.
- you want to be able to pass your class to an existing API expecting A's then you need to use inheritance.
- you want to enhance A, but A is final and can no further be subclassed then you need to use composition and delegation.
lothar
2009-05-07 02:46:12
A:
I won't expand on the answers given, however a book I've found really useful with these sorts of OO design issues is Arthur Riel's excellent book Object-Oriented Design Heuristics.
http://www.davegardner.me.uk/reading/oo-design-heuristics/
http://www.amazon.co.uk/Object-oriented-Design-Heuristics-Arthur-Riel/dp/020163385X
Dave
2009-05-07 12:47:38