Smalltalk and Object Orientation: an Introduction - Free

You can find the methods which implement
dependents, addDependent: and
removeDependent: all defined in the class Object in the dependents access protocol (as
illustrated in Figure 25.3). Browse these methods yourself, they will help you to understand how the
dependency mechanism works.
25.3.4 A simple dependency example
This subsection presents a very simple dependency example, which we will develop further during the
chapter. It creates two objects and creates a dependency between them. The objects are instances of a
class DataObject and DependentObject. These classes are direct subclasses of Object. Create
the classes placing them in an appropriate class category (for example, dependency demo). For example:
Object subclass: #DataObject
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'dependency demo'
Then evaluate the following in a Workspace:
| temp1 temp2 |
temp1 := DataObject new.
temp2 := DependentObject new.
temp1 addDependent: temp2.
Transcript show: (temp1 dependents) printString.
temp1 inspect.
The result of the show message expression, printed in the Transcript, is:
#(a DependentObject)
Notice that, although the dependentObject instance was printed in the Transcript, no
dependents can be found for the dataObject in the inspector. Indeed no instance variable called
dependents can be found at all.
From the point of view of the class DataObject, dependency is an invisible mechanism which
works behind the scenes. Of course, this is not really the case. The dependency mechanism has been
inherited from Object and is implemented via message sends and method executions just like any
behavior provided by an object.
25.3.5 Making dependency work for you
We have now considered how we construct a dependency relationship. However, we want this
relationship to be used to inform the dependent object(s) that a change has occurred in the object on
which they depend. That is, we want to tell one object that another object, has changed in some way.
To do this we use two sets of methods. One set is used to state that something has changed. These
are called “changed” methods. The other set are used to state what type of update is required. These are
called “update” methods. They work as illustrated in Figure 25.4.
changed
message
dependents
ObjectA
update
message
update
message
ObjectB
ObjectC
Figure 25.4: The dependency mechanism in action
Figure 25.4 illustrates the sequence of messages which are sent in response to a change message
being sent to an obje ct. That is, when ObjectA is sent a changed message (usually by itself) all its
dependents are sent an update message. Again from the point of view of ObjectA much of this
behavior is hidden. In fact so much so that a point of confusion relates to the sending of one message
209