| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Finally, you can manage your Google Docs, uploads, and email attachments (plus Dropbox and Slack files) in one convenient place. Claim a free account, and in less than 2 minutes, Dokkio (from the makers of PBworks) can automatically organize your content for you.

View
 

Thoughts on learning Smalltalk

Page history last edited by PBworks 14 years, 5 months ago

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:

 

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

Comments (0)

You don't have permission to comment on this page.