[Newbies] RE: RE: delegation vs inheritance

Mon Aug 6 16:20:54 UTC 2007

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 

> -----Original Message-----
> From: Darren
> 
> 
> 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 at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/mailman/listinfo/beginners
> >
> >
> 
> --
> View this message in context: http://www.nabble.com/delegation-vs-
> inheritance-tf4216781.html#a12013376
> Sent from the Squeak - Beginners mailing list archive at Nabble.com.
> 
> _______________________________________________
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners