13.3: Object-Oriented Design- Model-View-Controller Architecture

Java’s Swing components have been implemented using an object-oriented design known as the model-view-controller (MVC) model. Any Swing component can be considered in terms of three independent aspects: what state it’s in (its model), how it looks (its view), and what it does (its controller).

For example, a button’s role is to appear on the interface waiting to be clicked. When it is clicked, the button’s appearance changes. It looks pushed in or it changes color briefly, and then it changes back to its original (unclicked) appearance. In the MVC model, this aspect of the button is its view. If you were designing an interface for a button, you would need visual representations for both the clicked and the unclicked button (as well as other possible states).

When you click a button, its internal state changes from pressed to unpressed. You’ve also probably seen buttons that were disabled—that is, in a state where they just ignore your clicks. Whether a button is enabled or disabled and whether it is pressed or not are properties of its internal state. Taken together, such properties constitute the button’s model. Of course, a button’s view—how it looks—depends on its model. When a button is pressed, it has one appearance, and when it is disabled, it has another.

Because a button’s state will change when it is clicked or when it is enabled by the program, some object needs to keep track of these changes. That part of the component is its controller.

Figure [fig-mvc] shows how the button’s model, view, and controller interact with each other. Suppose the user clicks the button. This action is detected by the controller. Whenever the mouse button is pressed, the controller tells the model to change into the pressed state. The model, in turn, generates an event that is passed to the view. The event tells the view that the button needs to be redrawn to reflect its change in state.

When the mouse button is released, a similar sequence of events occurs. The model is told to change to the unpressed state. It in turn generates an event, handled by the view, which changes the button’s appearance.

A change in the button’s appearance does not necessarily depend on direct action by the user. For example, the program itself could call a method that disables the button. In this case, the program issues a to the model, which in turn generates an event that causes the view to change the object’s appearance.

For some Swing components, such as the text components, this three-part model is implemented almost exactly as we just described. For others, such as JButton, one class is used to implement both the view and the controller. The JButton model is defined in the DefaultButtonModel class, and its view and controller are defined in the BasicButtonUI class (The UI acronym stands for User Interface). The point is that for some components, Swing has organized the view and control—the look and the feel—into a single class.

Pluggable Look and Feel

The MVC model uses a clear division of labor to implement a GUI component. The main advantage of this design is the independence between the model, the view, and the controller. If you want to give a button a different look and feel, you can redefine its view and its controller.

By combining the view and controller into a single class, Swing makes it even easier to change a component’s look and feel. For example, to design your own look and feel for a JButton, you would define a class that implemented all of the methods in the BasicButtonUI. Of course, this is a job for an experienced software developer.

However, if you just want to set your program to use one of the pre-defined look and feel models, you can simply use the UIManager.setLookAndFeel() method:

public static void main (String args[]){
  try{
     UIManager.setLookAndFeel(
        "javax.swing.plaf.metal.MetalLookAndFeel");
  }catch (Exception e) {
     System.out.err("Exception: " + e.getMessage());
  }
}//main()

Java’s default, the Metal look and feel, has been designed specifically for Java applications. For a Windows look, you can use the following argument: com.sun.java.swing.plaf.windows.WindowsLookAndFeel.

Figure 13.4 shows how the simple application would appear under the three different look-and-feel styles.

The MVC architecture is a model of object-oriented design. But if a JButton is really composed of three separate parts, how can we still call it a component? Isn’t it really three things?