Ah Ha!! 7 November, 2006

The following was origanally posted to the beginners list. If you have questions the beginners list is a good place to go for help. You can find the beginners list here.

Learning Smalltalk is definitely and experience. There is a major “Ah-ha!” moment prerequisite. It is really amazing to see people hit that “Ah-ha!”.

Some people do it quickly but most take some time. I’ve seen it come after even a years worth of practical hands on programming, so don’t get frustrated if it doesn’t come right away.

The best I can do to help you is to give you some hints on how to get there yourself.

1) Object message. Programming in Smalltalk really doesn’t get much harder then this concept. Object message.

it := Consider theConcept.

you := Person new.

you live: it.

you breathe: it.

you sleepOn: it.

What is the Object? (An instance of a class or class definition)

What is the message?

Everything is Smalltalk follows this pattern; there is an Object and a message. The message or method may have parameter.

2) Your code goes everywhere! One of the first questions I’m always asked is; “Where does my code go?” The answer is EVERYWHERE! In Smalltalk you are building objects. By that I mean you can model real things. Pick anything and think of it as a component of the rest of the system, and consider what components make up this thing. For example: aShoe.

aShoe := Shoe new.

aShoe laces: ShoeLace greenLaces.

aShoe color: Color green.

aShoe price: (USDollars dollarValue: 12).

aShoe owner: aManufacturer.

You can see that there are many different components or Objects that can make up what you are modeling. Relationships can be modeled, new components can be added, you are free to model what ever you want. So where does your code go? It goes where it is needed. It goes in the object that needs that code.

For example sell a shoe:

Manufacturer>>sell: aShoe to: aPerson

“sell a shoe to aPerson collect price, update books and decrease inventory”

aPerson collectMoney: aShoe price.

self updateMonthyBooks: (Sales item: aShoe price: aShoe price date:

Date today).

hasInventory := self removeFromInventory: aShoe.

hasInventory ifFalse: [

self backOrder: aShoe

].

You can see lots of objects that are implied in this code but look at where the code is. aPerson which is an instance of Person is responsible for paying so collectMoney: is on Person. There could be lots of ways that a person could pay so let the person object handle that. The manufacturer has its own account books so it should be able to updateMonthlyBooks: which could be sent to an AccountingSystem instance.

I also hear: “Once I make a really great shoe, how do I hook that into the rest of the system?” This really confuses some people. Try to see your program as more then just pieces, but instead as a whole entity. When you realize that your program could start like this: ShoeStore open. Or MyWorld turn. Or MyWorldsTime start. Or Universe explode. It’s easy to consider how a shoe might fit in your program.

3) Polymorphism and Inheritance. Do I need to understand these to understand Smalltalk? YES!! But don’t worry. They are big words for simple concepts. You are a child of your parents. You inherit certain characteristics from them, which make you like your parents, but you change some of the characteristics to allow you to be more of yourself (polymorphism). Polymorphism means having many forms. So how does that help? The concept of objects would be good enough and still be very powerful without this functionality but when you add in Inheritance and Polymorphism you really start to cook! These concepts really get things moving and allow you to do some fantastic programming. Let’s extend the shoe store example. What if we wanted to sell socks or shoe polish, or custom shoe laces? What are the things that are similar that could be modeled as a superclass so that our salesItems could inherit those behaviors? Object subclass: SalesItems

instanceVariables: ‘purchaseDate purchasePrice manufacturer’

SalesItem subclass: Shoe

SalesItem subclass: ShoePolish

SalesItem subclass: ShoeString

You can see from this example that subclasses of SalesItem inherits the instanceVariables purchaseDate purchasePrice and manufacturer.

We could implement methods on SalesItems that allow us to sell a general item without having to implement these methods on every item. That is the power of inheritance.

Now what things need to be different for each item? Since I’m making this up as I go let me apologize if this is not the best example.

Say that our store likes to make funky shoes by buying them from the manufacturer, then changing the laces. We also sell other funky laces, and we allow people to change the laces before they leave the store if they want too. How are we going to keep track of all this?

We want to be able to just sell and item without having to worry about this, so

SalesItem>>removeFromInventory: anInventory

“remove this item from anInventory”

anInventory removeFromInventory: self.

Now if you call this method on ShoePolish then anInvetory will removeFromInventory: self (self is an instance of ShoePolish since this method is called from there). This method is inherited.

Let’s change things for Shoe

Shoe>>removeFromInventory: anInventory

“remove this item and it’s shoe laces from anInventory and replace shoelace if necessary”

| lacesWereChanged theShoesLaces |

anInventory removeFromInventory: self.

lacesWereChanged := self askUserIf: ‘Were the laces changed?’.

theShoesLaces := lacesWereChanged

ifTrue: [self askUser: ‘Please select laces from list’ forItemInList: anInventory shoeLacesList]

ifFalse: [self laces].

anInventory removeFromInventory: theShoesLaces.

Now this is polymorphism. When you remove an item from inventory it will do what you want since it inherits a method from SalesItems. If it doesn’t do what you want you can give your object its own personality by changing what it does. This is polymorphism.

Go forth and Smalltalk, and if you have questions feel free to ask! This is the place to do it.

Ron Teitelbaum

President / Principal Software Engineer

US Medical Record Specialists

Ron@USMedRec.com