delegation vs inheritance

First of all I must apologise if I get some terminology wrong in this post.

I was rummaging around the collection classes earlier today and came across class Stack. I was interested to see that it makes use of class LinkedList through delegation with a instance variable rather than inheritance.
I'm tyring to remember my Analysis and Design course here. I have a foggy memory about a is-a and has-a relationship. So a ford is-a type of Car, so that is a inheritance relationship and a Car has an engine so that is a delegation relationship. I also know that delegation is better for loose Coupling.

As you can see I'm a bit vague on all this. With class Stack what would the be the likely thinking to delegate as apposed to inherit? I think this is a very impotent subject and I would like to be clearer on it.

Hello,

I have to ask is Grunt your real name?  Do you have a real name?  

Ok so your question is very vague.  I'll try to answer, but I'm not sure my
answer will be much help.

Stack is a specialization of Object

Stack has a linked list

Stack normally implements linked list as a collection of StackLinks.

StackLink is a specialization of Link

Link has a nextLink that normally points to an instance of Link (or it's
subclasses) to provide a linked list structure.  

Does that help?

Ron



_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Hi,

On 8/4/07, Ron Teitelbaum <[hidden email]> wrote:
> I have to ask is Grunt your real name?  Do you have a real name?

indeed. I'd be interested to know as well.

Apart from what Ron has answered, I'd like to point out that Stack
does not delegate to LinkedList; what is being done there is
forwarding. The difference is subtle but important in certain
settings.

In case Stack would delegate to LinkedList, "self" would be the Stack
instance in all LinkedList methods invoked during Stack operations.
Delegation, however, is not supported directly in Smalltalk. Instead,
Stack forwards requests to LinkedList, implying that "self" is bound
to a LinkedList instance instead of a Stack instance in all LinkedList
methods invoked during Stack operations.

More on this can be found on
http://javalab.cs.uni-bonn.de/research/darwin/delegation.html.

Best,

Michael
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

from: Ron Teitelbaum
>Hello,
>I have to ask is Grunt your real name?  Do you have a real name?  

Oh, OK then, it's Darren :-)

>Ok so your question is very vague.  I'll try to answer, but I'm not sure my
answer will be much help.
>Stack is a specialization of Object
>Stack has a linked list
>Stack normally implements linked list as a collection of StackLinks.
>StackLink is a specialization of Link
>Link has a nextLink that normally points to an instance of Link (or it's
subclasses) to provide a linked list structure.  

>Does that help?

>Ron
 
Thanks Ron, yes that does help but also what would be the thought process (I know you can't read minds) to choose this approach as apposed to specializing StackLink?

-Regards Darren

Hi Michael,

Thanks for the reply. I find it very interesting what you say but am struggling to understand it and the info in the link. I have googled "forwarding vs delegation" but am still confused. I think what I need to do is explore this in the morning when my brain is fresh.
I know this isn't squeak specific but I would rather ask here than a PHP group!

-Regards, Darren


from: Michael Haupt-3
>Hi,

On 8/4/07, Ron Teitelbaum <Ron@usmedrec.com> wrote:
> I have to ask is Grunt your real name?  Do you have a real name?

>indeed. I'd be interested to know as well.

>Apart from what Ron has answered, I'd like to point out that Stack
does not delegate to LinkedList; what is being done there is
forwarding. The difference is subtle but important in certain
settings.

>In case Stack would delegate to LinkedList, "self" would be the Stack
instance in all LinkedList methods invoked during Stack operations.
Delegation, however, is not supported directly in Smalltalk. Instead,
Stack forwards requests to LinkedList, implying that "self" is bound
to a LinkedList instance instead of a Stack instance in all LinkedList
methods invoked during Stack operations.

>More on this can be found on
>http://javalab.cs.uni-bonn.de/research/darwin/delegation.html.

>Best,

>Michael

Hi Darren,

On 8/4/07, gruntfuttuck <[hidden email]> wrote:
> Thanks for the reply. I find it very interesting what you say but am
> struggling to understand it and the info in the link.

it's something that may be difficult to grasp indeed. Maybe it's my
explanations that get it wrong. I'll try again, please bear with me.
:-)

In some very few words: if, during the execution of a message that
made it from A to B somehow, "self" remains bound to A, it's
delegation. If "self" changes to B, it's forwarding.

Some other words: if B acts "on behalf of" A (but the credits go to A
in the end), it's delegation. If B acts because A tells it to and B
gets the credit, it's forwarding.

("On behalf of" meaning "in the name of" above.)

I *should* come up with an actual example, I know. :-) But the page I
pointed you to actually does a good job already. (BTW I noticed they
call "forwarding" "consultation"... well... names...)

> I think what I need to do is explore this in the morning when my brain is fresh.

That's always a good idea... :-)

Best,

Michael
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

I don't understand your question.  What are you trying to do or which
thought process doesn't make sense?  

If you are trying to provide a linked list then you should use Link.  If you
need a stack use Stack.  Have a look at the methods on each class and you
can see how each class has been specialized.  That should give you an idea
of which class meets your needs.  (If you don't find a method you need on
Link, but it's on stack then use Stack)

I think it would be easier if you said more about what you would like to do
or what you do not understand.  I'm sure someone can help explain it.  I'm
still not sure what piece you are having difficulty with.

Welcome Darren!

Ron

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Hi Ron

Sorry for the confusion. I'm just using Stack as an example, I don't need to use it. I'm just curios of the design choose between delegating (or forwarding) vs inheritance. Couldn't Stack inherit from LinkedList and specialize it. I'm not questioning the design choose but just trying to learn how to make good design decisions.

Regards, Darren

Ron Teitelbaum wrote

> From: Darren
>
>
> from: Ron Teitelbaum
> >Does that help?
> >Ron
>
> Thanks Ron, yes that does help but also what would be the thought process
> (I
> know you can't read minds) to choose this approach as apposed to
> specializing StackLink?
>
> -Regards Darren
>

I don't understand your question.  What are you trying to do or which
thought process doesn't make sense?  

If you are trying to provide a linked list then you should use Link.  If you
need a stack use Stack.  Have a look at the methods on each class and you
can see how each class has been specialized.  That should give you an idea
of which class meets your needs.  (If you don't find a method you need on
Link, but it's on stack then use Stack)

I think it would be easier if you said more about what you would like to do
or what you do not understand.  I'm sure someone can help explain it.  I'm
still not sure what piece you are having difficulty with.

Welcome Darren!

Ron

_______________________________________________
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners

from: Michael Haupt-3

>In some very few words: if, during the execution of a message that
made it from A to B somehow, "self" remains bound to A, it's
delegation. If "self" changes to B, it's forwarding.

I get it now. I read you message again in the morning and -ping- clarity. Same with the linked article.
Thanks you for your help.

Regards, Darren

Hi Darren,

You can see an example of delegation when is send 'super foo' within a
method foo on A.
Then whoever is super, it will fullfill message foo with its implementation
on behalf of A.
So every time self is found, A will receive the message.

Regards.

        Emilio

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Hi Darren,

Ok I get it now.  Consider a stack and a linked list.  The stack is a
separate entity that understands how to add and remove from the list.  If
you only used the linked list there would be no single object to talk too.
You could have code that says find the top object from any object you are
holding but that would be pretty messy and quite difficult if the one item
you are holding onto gets removed.  

In order to wrap your mind around objects you really need to understand the
difference between instances and class definitions.  Picture your objects as
real things that are created from definitions.  (Stack is a definition.
aStack := Stack new.  aStack is an instance of Stack.)

For aStack we have an instance that holds onto a linked list.  The Stack
instance itself receives messages and operates on the linked lists.  You
could picture holding a linked list like holding a single monkey out of a
barrel of monkeys.  Which one would you hold, and it gets complicated when
some start getting added or dropped.  When you drop the last one back into
the barrel you have nothing to hold onto.  

By creating a stack object we build something that is more natural and
understandable then extending a linked list to accept stack messages.  Say
for example you decide that we will just talk to the first link.  It seems
odd to have to traverse the list to remove an item and it's not really what
a linked list is supposed to do.

The best advice I can give you is to see your objects as real things.
Knowing when to create a new object or extend an existing object is indeed
an important skill.  There are some rules you can follow.  

1) Methods should be short.  You know you are doing things properly when
your methods are only a few lines long.

2) Most methods take only a few parameters.  If you find you are sending in
a huge number of parameters then your class or your methods are too complex.
You would probably benefit from creating a Method or Model class.  You
factor your complex method into a model, the instance variables are usually
the parameters of your methods.  You will find that having a model class
greatly simplifies your program flow and significantly simplifies your code.
Where you once were passing the world from one method to the next you can
now just say: self myPieceOfTheWorld doSomething.

3) Most instance methods refer to #self.  If you are passing in an object
and working on that object and your method has an identity crisis (no sense
of self) then you are writing your code on the wrong class.  Look at your
parameters and you will notice that the code really belongs on one of those
instead.  Writing the code on the right class is a skill worth developing.

4) If you created a door that doesn't open, or that pumps water from your
well then you are not modeling the real world.  Try to keep the behaviors of
your objects to the things they should be doing.  Don't add functionality to
an object that is really the responsibility of a new, or some other existing
object.  Feel free to code behavior that belongs to the object but stay true
to what that object is meant to do.  You will find later that when you look
for behavior it's much easier to find if the code is on the object that
should be responsible for it.

5) Don't be afraid of creating new classes.  Use as many objects as you need
but no more!

Hope that helps!!

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists
www.USMedRec.com

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

> Sorry for the confusion. I'm just using Stack as an example, I don't need to
> use it. I'm just curios of the design choose between delegating (or
> forwarding) vs inheritance. Couldn't Stack inherit from LinkedList and
> specialize it. I'm not questioning the design choose but just trying to
> learn how to make good design decisions.
>

When trying to decide between inheritance (IS-A) and delegation
(HAS-A) for a new class consider how the behavior of the new class is
related to the old.  Should the new class have all the same behavior
(support all the messages) that the old class did?

In the case of a Stack either having an IS-A or HAS-A association with
a LinkedList.  Should a stack support all the behavior of a linked
list?  The answer is a resounding no.  A stack is supposed to have
LIFO (last in first out) behavior while a linked list provides the
ability to alter the  list at any point which would break the stack
behavior if exposed.  Also the stack only needs the following behavior
push, pop, and count the linked list would provide too broad of an
interface.'

The IS-A (inheritance) relationship means that everything that the
base class is/provides is also true of the subclass (with some
extensions or behavioral modification).

I'd recommend reading the gang of four's "Design Pattern's" book, it
has a nice discussion of inheritance and delegation.

Hope that helps,
Robert
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Hello All

Thank you so much for taking the time to enlighten me on the design choose between  inheritance and delegation. It would seem to me that such chooses is are at the core of all patterns and best practises. I hope the explanation will be of use to others too.
I have my eye on the book; The Design Patterns Smalltalk Companion and I allready have the wonderful Smalltalk Best Practice Patterns by Kent Beck.
I feel I should say more in resonce to all the replays but because they were so clear and helpful I have no more questions - I get it! Thank you.

Regards, Darren