Java Reference
In-Depth Information
was coupled to classes Fox and Rabbit , because it creates the initial instances.) Instead, we
can introduce an interface ActorFactory and classes implementing this interface for each ac-
tor (for example, FoxFactory and RabbitFactory ). The Simulator would simply store a
collection of ActorFactory objects, and it would ask each of them to produce a number of ac-
tors. Each factory would, of course, produce a different kind of actor, but the Simulator talks
to them via the ActorFactory interface.
In the discussions of several of the projects in this topic, we have tried to separate the internal
model of the application from the way it is presented on screen (the view). The Observer pat-
tern provides one way of achieving this model/view separation.
More generally, the Observer pattern defines a one-to-many relationship so that when one ob-
ject changes its state, many others can be notified. It achieves this with a very low degree of
coupling between the observers and the observed object.
We can see from this that the Observer pattern not only supports a decoupled view on the
model, but it also allows for multiple different views (either as alternatives or simultaneously).
As an example, we can again use our foxes-and-rabbits simulation.
In the simulation, we presented the animal populations on screen in a two-dimensional ani-
mated grid. There are other possibilities. We might have preferred to show the population as
a graph of population numbers along a timeline or as an animated bar chart (Figure 13.3). We
might even like to see all representations at the same time.
Figure 13.3
Multiple views of one
Search WWH ::

Custom Search