Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com

Observer and Observable

An introduction to the Observer interface and Observable class using the Model/View/Controller architecture as a guide

By Todd Sundsted, JavaWorld.com, 10/01/96

Here's the problem: You're designing a program that will render data describing a three-dimensional scene in two dimensions. The program must be modular and must permit multiple, simultaneous views of the same scene. Each view must be able to display the scene from a different vantage point, under different lighting conditions. More importantly, if any portion of the underlying scene changes, the views must update themselves.

None of these requirements presents an insurmountable programming challenge. If the code that handles each requirement had to be written de novo, however, it would add significant work to the overall effort. Fortunately, support for these tasks is already provided by the Java class library in the form of interface Observer and class Observable. The functionalities of these two were inspired, in part, by the requirements of the Model/View/Controller architecture.

The Model/View/Controller architecture

The Model/View/Controller architecture was introduced as part of the Smalltalk-80 version of the Smalltalk programming language (a popular object-oriented programming language invented by Alan Kay). The Model/View/Controller architecture was designed to reduce the programming effort required to build systems that made use of multiple, synchronized presentations of the same data. Its central characteristics are that the model, the controllers, and the views are treated as separate entities, and that changes made to the model should be reflected automatically in each of the views.

In addition to the program example described in the opening paragraph above, the Model/View/Controller architecture may be used for projects such as the following:

  • A graph package that contains simultaneous bar-chart, line-chart, and pie-chart views of the same data

  • A CAD system, in which portions of the design can be viewed at different magnifications, in different windows, and at different scales



Figure 1 illustrates the Model/View/Controller architecture in its most general form. There is one model. Multiple controllers manipulate the model; multiple views display the data in the model, and change as the state of the model changes.



The MVC Architecture



Figure 1: The Model/View/Controller architecture

The Model/View/Controller architecture has several benefits:

  • There is a clearly defined separation between components of a program -- problems in each domain can be solved independently.

  • There is a well defined API -- anything that uses the API properly can replace either the model, the view, or the controller.

  • The binding between the model and the view is dynamic -- it occurs at run time, rather than at compile time.



By incorporating the Model/View/Controller architecture into a design, pieces of a program can be designed separately (and designed to do their job well) and then bound together at run time. If a component is later deemed to be unsuitable, it can be replaced without affecting the other pieces. Contrast that scenario with the monolithic approach typical of many quick-and-dirty Java programs. Often a frame contains all of the state, handles all events, does all of the calculations, and displays the result. Thus, in all but the simplest of such systems, making changes after the fact is not trivial.

1 | 2 | 3 | 4 | 5 | 6 | 7 |  Next >
Resources