CISC 3115

Exercise 4: Model-View-Controller (Introduction)

Objectives:

Overview

In this exercise, we're going to focus on the Model-View-Controller design pattern we talked about briefly in class. There are two reasons for this: (1) MVC is a very commonly used design pattern, across many languages and application contexts; (2) MVC is (I think) a helpful way of thinking concretely about design, about how you can create effective relationships among objects in your applications.

This exercise has two parts. First, we'll look at another version of the "SwingLine" code that we looked at during the application activities, and we'll see how the code can be "refactored" to make it even more MVC-ish. Then, we'll look at how Swing itself uses MVC to design many of the Swing components. This will involve a fair amount of API-reading, and not so much code-writing... but that's actually how things go a lot of the time: you have to read a fair amount before you figure out how to write a couple lines of code.

MVC Intro/Review

I talked for a few minutes in class about Model-View-Controller. That was no accident. While there are many design patterns floating around Java, MVC shows up a lot in Swing. And beginning to think in terms of design patterns is an important step in your development as a software developer. (For example, there are a ton of books written about design patterns, many focusing on a particular programming language.)

As we saw in the big-small-circle application, MVC is often used to structure the user interface of an application; it's a useful way make sure we're keeping the three kinds of behavior (keeping track of data [the model], displaying the data [the view], and letting the user change the data [the controller]) fairly separate from each other (and therefore making sure that we're not programming like that jerk Larry).

SwingLine MVC

Here is the source code for a "fully" Model-View-Controller version of the SwingLine application we also looked at last week. Take a look. The big difference between last week's version and this week's version is that I put the "application data" (in this case, the length and thickness of the line) into its own class, which I called LineModel. Most of the behavior in this class is essentially getter and setter behavior. But there is some additional code relating to the fact that this is part of an MVC design: when the data in the model changes, other objects (especially the View) may want to know about the change so they can update in response. So, I wrote LineModel to extend Observable. The Observable class offers the basic behavior of allowing other objects to "register" as "listeners" (similar to buttons and ActionListenerss). So a class that extends Observable gets all that behavior automatically. You'll also see that the main application class implements the Observer interface, which includes a single method, update(). My definition of the update() method tells the various elements of my View to update themselves with the new data from the Model. Read the documentation for Observable and Observer—you'll see that these have been deprecated because they're not as flexible and powerful and modern applications require, but they're still very good for exploring the foundational concepts.

In class, I'll ask you to modify the behavior of this application.

Swing and MVC

Let's switch gears a bit and look at Swing components themselves. For example, what do we know about the JTextField class. Which of the following are responsibilities/behaviors of this class?

  1. Store some text data
  2. Display some text data
  3. Respond to some keyboard entries

While you're thinking about that, look at the JList discussion on p. 417 of the book. Which of these are responsibilities of this class?

  1. Store a list of objects
  2. Remember which objects have been "selected"
  3. Display the values of the objects in the list
  4. Respond to mouse-clicks
Actually, most of the Swing UI components have these responsibilities: storing some data, presenting that data, and allowing users to interact with that data. (OK, a JButton doesn't have that much going on—but that's one of the exceptions.) By the way, for those two multiple choice questions, all of the listed items are correct. In preparation for this week's exercise read this short excerpt that discusses MVC generally as well as its application within Swing. Also, read the introductory text in the documentation for JList, paying particular attention to the discussions about ListModel, ListSelectionModel, and how cells are "painted" (i.e. the View).

In class, I'll walk you through how to customize some of the behavior of a JList.