Smalltalk and Object Orientation: an Introduction - Free

(i.e. the changed message) and the execution of another method (i.e. the update method). That is, a
programmer defining Objects A, B and C will:
1. send a changed message to ObjectA
2. define an update method in ObjectB and ObjectC.
The confusion here stems from the need to send one message but define another. However, if you think
about how you are linking into the existing dependency framework, it can make more sense. Essentially
the change message is a message to the dep endency mechanism asking it to notify the object’s
dependents about a change. The dependency mechanism is inherited and is generic across applications.
However, there is no way that the system developers could know when the change message should be
sent. That is application specific. It is therefore the application developer’s responsibility to send the
changed message. For example, you may only want dependents to get told of certain changes, such as
updates to only one field on an input screen etc.
In turn , there is no way that the system developers could have known how you would want the
dependents to update themselves. The update message could indicate that the new value produced by
the originating object should be displayed, that some calculation should be re -performed, or that a
database should be accessed. In fact in the default implementation, inherited from Object, the update
methods do nothing. They are only there so that an error is not generated if a message is sent to an
object which does not have a new update method defined for it.
In the simple ObjectA, ObjectB and ObjectC example above, we would need to specify what
ObjectB and ObjectC should do when ObjectA changed. This would require defining our own
update methods.
25.3.6 The “changed” methods
There are three different changed messages which take zero, one or two parameters. They are:
anObject changed: anAspect with: aParameter.
anObject changed: anAspect.
anObject changed.
The first point to note about the changed messages are that they are sent to the object which has
changed in some way. That is, they are used to inform the object that a change has taken place to it and
that this change should be passed onto any dependents it may have. That is, the changed message does
not effect the change, nor is it sent to the objects which wish to be notified about the change, rather it is
telling the changed object that it should notify the dependency mechanism of the change.
Each of the three messages will trigger off the update part of the dependency mechanism. The only
difference between the messages relates to the amount of information provided. The first message can
be used to not only tell the dependent objects what aspect of the object changed but also what the new
value produced by the change was. For example, the aspect that has been modified might be an instance
variable and the parameter the new value of the instance variable. In turn the second message only tells
the dependents what aspect has changed, while the third only in forms the dependents that some change
has taken place. Therefore the simplest changed message (and the one with the least information) is the
changed message. This can be useful when you want to make sure that the dependents assume
nothing about the object to which the change is happening.
A point to note is that the way that these messages are implemented is that the changed method calls
the changed: method with nil as a parameter. In turn this method calls the changed:with:
method with the parameter pass ed to it and a nil parameter. Thus if you wish to modify the way that
the dependency mechanism works, the changed side is encapsulated within the changed:with:
method.
25.3.7 The “update” methods
There are three different versions of the update messages which take one, two or three parameters. They
are:
update: anAspect with: aParameter from: anObject
update: anAspect with: aParameter
update: anAspect
210