Smalltalk and Object Orientation: an Introduction - Free

model
4. update
1. balance
(view)
0
Deposit
(statement)
balance
2. deposit
(controller)
3. changed:
#balance
Figure 26.8: Tracing the interactions in the MVC
The view is displaying a very simple window, which can display the curre nt balance and a button
labeled deposit. The controller is responsible for responding to the button click.
The sequence of message which would be sent between these objects as the window was created and
a user interacted with the window are illustrated in Figure 26.8 and described below:
1. The statement object is instantiated and the view is opened. The view object must first draw the
window. To determine the current balance it must send the message balance to its model ( the
statement). The returned value is then displayed in the output field.
The user clicks the mouse in the area of the screen used to display the button. The controller
sees this click and enters into a dialogue with the view to determine if the click was actually
within the button or not 12 . If it was, then the controller must send a message to the model to tell it
to deposit ten pounds (we are assuming every deposit equals ten pounds for simplicity). This is
done by sending the message:
model deposit: 10.
2. The model (a statement) receives the message deposit and records this. It then updates the
current balance and sends itself a changed message, e.g.:
balance: newAmount
balance := newAmount
self changed: #balance.
3. Because the model sent itself the cha nged message, an update message is sent to its dependents,
one of which is the view.
4. The view receives the update message. Its implementation of update re -runs the code used to
create the balance view in the first place. That is, it sends the message balan ce to the model as in
step 1.
There are a number of points worth noting about this example. Firstly, the view does not record
anywhere what the actual balance is. It merely obtains the value from the model and displays it on the
screen. From that moment on it forgets it. Secondly, the controller must ask the view to determine if the
cursor is within the region of the button. That is, the controller does not know where on the screen the
button is displayed, nor does it attempt to obtain that information fro m the view. Thirdly, even though
the controller has direct access to the view, it does not tell the view what it is asking the model to do.
The view is unaware of any change in the model until it is sent an update message. At this point it
requests the cur rent balance from the model. Note that this means that if the statement was sent a
deposit message by some other object (rather than by the controller) it would still result in the view
being told to update itself. Finally, the model is unaware that the message:
deposit: 10.
came from the controller. It could have come from any object and thus the model is completely
insulated from the controller and the view.
12
We will come back to this issue of which controller actually catches the input and which view is questioned about the
position of the cursor at a later d ate.
219