Hi Greg,

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:

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?

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

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

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