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@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@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners