Smalltalk and Object Orientation: an Introduction - Free
Smalltalk and Object Orientation: an Introduction - Free
Smalltalk and Object Orientation: an Introduction - Free
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Point 2 above is more complicated. For the first time we have encountered a situation where we<br />
w<strong>an</strong>t one object’s state (the value of its ins t<strong>an</strong>ce variable) to be dependent on information provided by<br />
other objects. If we were to write down procedurally how the value of other objects affected the status<br />
of the pump, we might get:<br />
if fuse is working then<br />
if switch is not off then<br />
if relay is working then<br />
pump status := ‘working’<br />
endif<br />
endif<br />
endif<br />
This algorithm says that the pump status depends on the relay status, the switch setting <strong><strong>an</strong>d</strong> the fuse<br />
status. This is the sort of algorithm you might expect to find in a main() program. It link s all the sub<br />
functions together <strong><strong>an</strong>d</strong> processes the data.<br />
Of course in <strong>an</strong> object oriented l<strong>an</strong>guage (such as <strong>Smalltalk</strong>) we don’t have a main program. In <strong>an</strong><br />
object oriented system we have well m<strong>an</strong>nered objects passing messages between one <strong>an</strong>other. How<br />
then do we achieve the same effect as the above algorithm? The <strong>an</strong>swer is that we must get the objects<br />
to pass messages requesting the appropriate information. One way to do that would be to define a<br />
method in the pump object which would get all the required infor mation from the other objects <strong><strong>an</strong>d</strong><br />
determine the motors state. However, this would require that the pump had links to all the other objects<br />
so that it could send them messages. This is a little contrived <strong><strong>an</strong>d</strong> loses the structure of the underlying<br />
system. It also loses <strong>an</strong>y modularity in the system. That is, if we w<strong>an</strong>t to add new components then we<br />
would have to ch<strong>an</strong>ge the pump object, even if the new components only affect the switch. This<br />
approach also indicates that the developer is thinking too procedurally <strong><strong>an</strong>d</strong> not really in terms of objects.<br />
Now let us consider the object oriented view of this system. The pump object only really needs to<br />
know what state the relay is in. It should therefore request this information from the relay. In turn the<br />
relay must request information from the switches <strong><strong>an</strong>d</strong> the fuse. This is illustrated in Figure 3.4.<br />
This figure illustrates the chain of messages initiated by the pump object. That is, the pump object<br />
sends a message working to the relay, then:<br />
1. relay sends a message state to the switch<br />
the switch replies to the switch<br />
2. relay sends a second message working? to the fuse<br />
the fuse replies to the relay<br />
3. the relay replies to the motor<br />
If at this point the pump is working, then the pump object sends on the final message to the water bottle.<br />
4. pump sends a message extract to the water bottle.<br />
Wash wipe<br />
switch<br />
2. state?<br />
Wiper motor<br />
Relay<br />
1. working?<br />
Fuse<br />
3. working?<br />
Pump<br />
working?<br />
4. extract(pump status)<br />
Water bottle<br />
Figure 3.4: Collaborations between the objects for wash operation<br />
In this last case a parameter has been passed with the message, this is because, unlike all the previous<br />
messages which were merely requesting state information, this message is requesting a ch<strong>an</strong>ge in state.<br />
The parameter indicates the rate at which the pump is drawing water from the water bottle.<br />
Note that the water bottle should not record the value of the pump’s status as it does not own this<br />
value. That is, if it should ever need the motor’s status in the future it should request it from the pump<br />
rather th<strong>an</strong> using the (potentially obsolete) value passed to it.<br />
38
Change language