Smalltalk and Object Orientation: an Introduction - Free

uild a running user interface from the output of the user interface builder. Therefore by inheriting from
ApplicationModel, the new class (called ToDoOrganiser in Figure 27.6) is able to create user
interfaces.
You may note that in Figure 27.6 I also specified a ‘Selector’ called windowSpec. This is actually
where the window specification will be placed. The selector is actually the name of a class side method
defined within a class protocol called interface specs, which return s a windowSpecification. This is
actually an array of widget specifications. This approach allows different windows to be defined for the
same class and saved under different names. For example, we could construct a welcome window, an
input window and an o utput window for some class and call each of them by different selector names.
We could then choose which window we wished to open using the openInterface: message. Note
that by default it is the window defined by the specification held in windowSpec which is created in
response to an open message. Therefore:
• aToDoInterface open. This opens a window defined by the windowSpec class side
method.
• aToDoOrganizer openInterface: #welcome. This opens the window defined by the welcome
class side method”
Once the window has been installed onto a class you now have the potential to create a graphical
application.
Figure 27.6: The Installer
27.5 Application models versus domain models
In the last chapter we talked about the MV C architecture and that the model was the element of the
MVC which held the data. However, in this chapter we have introduced a new class called
ApplicationModel (which if you are very observant you will have noticed in the last chapter was a
subclass of M odel). So where does that leave the good old MVC? Is the ApplicationModel the
original model from the MVC or is it something different?
In fact when we talked about the MVC we did actually state that there may be very many objects
involved in providing the functionality of the whole system, but that only one of them might act as the
model in the MVC. Essentially, the use of an explicit ApplicationModel class is really
acknowledgment of this. By creating a class which is intended to provide the behavior nec essary to
create and manage the graphic user interface the developer can encapsulate all the user interface
functionality they need in subclasses of this ApplicationModel.
227