As we have observed, programming in an object-oriented language like Smalltalk consists of designing objects and specifying their interactions. This means deciding what data each object will hold in its variables, and writing the methods that will act upon that data. But objects are not designed individually. The programmer does not have to specify every object in the program personally. This would be very wasteful, because so many objects in a program are actually alike.
Instead, the programmer specifies special objects, known in Smalltalk as classes. These classes act like templates or blueprints. Their task is to represent the functionality (the methods and the variables) that the programmer wants to put in the other objects in the program. These other objects are known in Smalltalk as instances. You can think of every object in Smalltalk as being either a class, or an instance.
As well as acting as templates, Smalltalk classes have another purpose. They are actually responsible for making the instance objects
Chapter 2
Instances
Class objects act as templates for instance objects, and are also responsible for manufacturing or instantiating them.
they represent. This process is called instantiation, as is shown in the diagram above. So, Smalltalk classes act both as templates for instances, and as factories which manufacture the instances they represent. Every instance is said to be an instance of the particular class which both manufactured it and represents it in template form.
This relationship between classes and instances means that class objects combine two types of code and data. There is the code and data which the class object itself contains (known as class methods and class variables), and there is the template for the code and data which instances of the class will contain (known as instance methods and instance variables). The class methods and variables implement the functionality which is associated with the actual manufacture of instances. The instance methods and variables do whatever the programmer has designed instances of this class to do.
Class objects only understand class methods, and instance objects only understand instance methods. This is a very important distinction, which frequently causes confusion. It is as well to try to get it clear in your mind before starting to program. If you expect your objects (classes and instances) to understand the messages you send them, you must send classes class messages and instances instance messages!
Every instance of a particular class has its own set of the instance variables defined in that class. They are not shared amongst instances.
So, if a class defines an instance variable called 'size', every instance of that class will have a separate variable called 'size'. The values of all
\ • - .•r' • • ' ;••- -' • - . '• ^. 1 ' - . ^
An Introduction to Objects
these 'size' variables can, and probably will, be different. The situation is different for class variables. These are defined in the class, but are visible to and shared between all instances of that class.
Although conceptually we might think that every instance of a class has its own identical copy of the instance methods defined in that class, in practice this would be very inefficient. So in Smalltalk, instances share the methods defined in their class. This means that if you alter the definition of an instance method in a class, all existing and future instances of that class will see and use the new definition.
All this class and instance stuff is rather complicated, so here is a summary:
Instance Variables
A separate set in every instance (not shared).
Class Variables
One set shared between the class and all its instances.
Instance Methods
Defined in the class, but only understood by instances.
Class Methods
Defined in the class, and only understood by the class.
Inheritance
We now know that because lots of Smalltalk objects are similar to each other, programmers don't design each and every one individually.
Instead, they create objects called classes, which are templates for objects called instances. You might think that a programmer could now go off and start writing classes, ask those classes to make instances of themselves, and thereby create a Smalltalk program. In theory this is true, but in practice not only are lots of instances similar to each other, but lots of classes are too. Smalltalk programmers take advantage of this similarity between classes using a concept called inheritance.
Inheritance allows the programmer to say in effect 'This new class is just like that existing one, except in the following ways.' The new class is called a subclass, and the existing class is called a superclass.
When two classes are related in this way the subclass is said to inherit from the superclass. In Smalltalk, classes can have many subclasses which inherit from them. However, each subclass can only inherit directly from one superclass. Every class can be both a subclass and a
Chapter 2
superclass. This gives rise to a sort of family tree of classes, called the inheritance hierarchy. In the diagram below, class C inherits from (is a subclass of) class A, and is inherited by (is the superclass of) classes D, E, and F.
Instances of any particular class understand all the methods defined in their class, and all the methods defined, in their class's superclasses. So an instance of class D would understand all the methods defined in D, C, A and so on up to the top of the tree. Just to confuse things further, if a method that an instance understands is actually defined in the instance's class (rather than in a superclass), the class is said to implement the method.
According to inheritance, instances of a class will contain all the instance variables defined in their class, and all the instance variables defined in their class's superclasses. So an instance of class G would have the instance variables defined in G, B, A and so on up to the top of the tree.
Note that normally you can make an instance of any class. In other words, it is not only those classes at the bottom of the hierarchy (the leaves of the tree) which can have instances. However, sometimes a programmer will design a class which is intended never to have instances. This doesn't mean it is useless though. It is there to collect together functionality which will be inherited by other classes which will have instances. Those classes which don't have instances are sometimes called abstract classes. In contrast, classes which are designed to have instances are called concrete classes.
A fragment of the class inheritance hierarchy showing how every class inherits from exactly one other class.
Is inherited by
An Introduction to Objects