Smalltalk and Object Orientation: an Introduction - Free

6.3.1 Class definitions
In Smalltalk the format of a class definition is the following:
NameOfSuperclass subclass: #NameOfClass
instanceVariableNames: 'instVarName1 instVarName2'
classVariableNames: 'ClassVarName1 ClassVarName2'
poolDictionaries: ''
category: 'Class protocol'
It is not necessary to remember this format precisely as the Smalltalk browsers will present the
above as a template for you to fill out whenever you wish to define a new class. The following is an
example of a class definition:
Object subclass: #Person
instanceVariableNames: 'name age'
classVariableNames: ''
poolDictionaries: ''
category: 'Example classes'
This definition states that I wish to define a new class, Person, which will be a subclass of the
Object class. My new class will possess two instance variables called name and age. It will has no
class variable s or pool dictionaries (we will discuss these later). Finally, it will be part of the class
category ‘Example Classes’. This last field is normally filled in for you by the system. It is derived
from whatever class category you are in when you attempt to define the new class.
Note that our class name is currently a symbol (see below for an explanation of a symbol) denoted
by a #. This is because we have not defined it yet and it is therefore not a class name. An error would be
raised if we tried just to use it as class name in the definition. As soon as the definition is complete, we
can forget about the #.
However, classes are not just use d as templates, they have three further responsibilities which
include; actually holding the methods, providing facilities for inheritance and creating instances. We
shall consider each of these separately below.
6.3.2 Classes and messages
When a message is actu ally sent to an object requesting it to perform some service, it is not the object
which possesses the method but the class. This is for efficiency reasons. For example, if each object
possessed a copy of all the methods defined for that class then there w ould be a great deal of
duplication. Instead, only the class possesses the method definitions. Thus when an object receives a
message, it searches its class for a method with the name in the message. If its own class does not
possess a method with the appr opriate name, it goes to its class’s superclass and searches again. This
search process continues up the class hierarchy until either an appropriate method is found or the class
hierarchy terminates (with the class Object). If this happens an error is raised.
If an appropriate method is found, then that method is then executed within the context of the object.
This means that although the definition of the method resides in the class, the method executes within
the object. Thus different objects can be exec uting the same method at the same time but without any
conflict.
Do not confuse methods with instance variables. Each instance possesses its own copy of the
instances variables (as each instance possesses its own state). Figure 6.1 illustrates this idea more
clearly.
6.3.3 Instances and instance variables
In Smalltalk objects are instances of classes. All instances of a class share the same responses to
messages (methods), but they will contain different data (i.e. they will possess a different “state”). For
example, the instances of class Point will all respond in the same way to messages inquiring about the
value of the x coordinate, but may provide different values.
The class defi nition consists of variable declarations and all method definitions. The different state
of each instance is maintained in one or more instance variables.
63