Smalltalk and Object Orientation: an Introduction - Free

• Inheritance (class to class relationships)
• Instantiation (class to instance)
• Part of or contains (instance to instance relationships)
However, there is another important relationship supported by Smalltalk, this is the depende ncy
relationship. This is where the state or behavior of one object is dependent on the state of another object.
For example, Figure 25.1 indicates that there are a set of dependency relationships between the objects
A to F.
B
C
A
E
D
Tail depends
on head
F
Figure 25.1: Dependency between objects
This figure illustrates that object A is dependent on some aspect of objects B and D. In turn object B
is dependent on some aspect of object C and so on.
In Smalltalk dependency is a relationship which can be used to relate two objects such that, as the
state of one changes, the state of another automatically changes in an appropriate manner. In such a
relationship we say that one object is dependent upon another.
25.3.1 Why do we want it?
The reasons for dependency are all down to change. That is, we wish to communicate the fact that one
object has changed its value to another object which may be interested in either the fact of the change or
the new value effected by the change. The dependency mechanism provides a way of communicating
such events in a generic implementation independent manner.
An obvious question is “why not just get an object to send messages to those interested in it?” The
answer to this is that if you know what objects you want to send messages to, then do so. However, if all
you know is that sometime, at a later date, some object may need to know something about the state of
an object (but at present we don’t know what that other object might be) then we cannot arrange to send
messages to that object - because we don’t know what it will be. However, the dependency mechanism
allows any object (whose class is a subclass of Object) to be involved in a dependency. A second
advantage is that we don’t have to know about the objects interested in the object we are working on.
All we need to know is that it might be involved in a dependency relationship and we can let the
(hidden) dependency mechanism take care of informing these unknown objects about the updates.
25.3.2 How does it work?
As is hinted at in the above section, the dependency mechanism is implemented in the class Object.
This of course means that, as all classes in Smalltalk are subclasses of Object, all objects can be
involved in a dependency. You can browse the Object class to explore the dependency mechanism. If
you use the implementors option off the message window menu you will find that some of the messages
are redefined lower down in the class hierarchy. This is purely for internal efficiency or specific
implementation reasons - you will still use the mechanism in the same way.
The basic implementation, inherited from Object, associates a collection of other objects with an
object. This collection holds the objects whic h are dependent on the object (collectively these objects
are known as the objects dependents ). For example, in Figure 25.2 the object ObjectA has two
dependents ObjectB and ObjectC. The links to the dependent objects are held separately from
ObjectA in a dependents list. ObjectA can access this list via the message dependents.
207