CSE190L Notes for Wednesday, 4/11/07

The original design patterns book was published in 1995 and there was a lot of excitement about it initially. Some of that excitement has died down, so it's not quite as important as it used to be. But this is still an important part of object-oriented programming that you should become familiar with. Employers still often ask about design patterns in interviews.

One of the most important things to remember about a design pattern is that it creates a new vocabulary for programmers. You might find yourself telling a fellow programmer that you're trying to figure out how to construct just one of a particular object and to provide access to the object while also guaranteeing that you don't end up with two of them. Your friend is likely to say, "the singleton pattern!" because that particular design problem is known and has been written about (it's one of the 23 patterns in the GOF book). Most of these common patterns are included in wikipedia, so you can read about it by looking up .

After talking about the general idea of patterns, Horstmann talks specifically about what is known as the Model/View/Controller design pattern or MVC. The MVC pattern was not included in the original pattern book, although the observer pattern is similar to part of the MVC pattern (the idea of separating the model from the view).

You should get used to this terminology because it's used a lot:

• The model stores the state of the underlying application. For a game-playing program, for example, it would keep track of information about the player and about the world.

• The view (and there might be more than one) gives the user a visual representation of the model. In a game, it might be the image of what the player sees. It also could be a panel that includes indicators like how much life the player has left or a scoreboard indicating how many poiints the player has earned. The views are not required to display the entire model. They can display just a part of it.

• The controller (and again, there might be several) is a set of user interface controls that allow the user to take some action in the world (press a button, fire a gun, quit the game, hover the mouse over something, etc).

In terms of the line mania programming assignment, I'm asking students to separate the controller code from the model/view code. You are to have a panel class that will keep track of the current state of the drawing and will do the actual drawing. In other words, the panel has the model (the state) and the view (the drawing). I've asked students to define all of the user interface controls in a separate frame class (buttons, listeners, etc). So the frame is the controller (the code that indicates how to interact with the user).

I spent the rest of the lecture talking about the idea of layout managers. We'll see that in writing Swing programs, you end up with deeply nested containers. The frame has something called the "content pane", which is a JPanel that stores its components. We've already seen that in the Colors program and the line mania assignment, we're putting two different things into the frame's container: a JPanel with buttons and a JPanel used for drawing. A typical Swing application tends to have many levels of containers (typically JPanels inside of JPanels inside of JPanels).

Each Container has an object associated with it called a layout manager. The layout manager decides the sizes and locations of the objects inside the container. To explore this, I added two new buttons in the frame class for our Colors example:

        private JPanel buttonPanel() {
            JPanel result = new JPanel();
            result.add(makeButton("Yellow", Color.YELLOW));
            result.add(makeButton("Blue", Color.BLUE));
            result.add(makeButton("Red", Color.RED));
            result.add(makeButton("Magenta", Color.MAGENTA));
            result.add(makeButton("Green", Color.GREEN));
            return result;
        }

        frame.add(panel, BorderLayout.CENTER);

        frame.add(buttonPanel(), BorderLayout.NORTH);

        frame.add(panel, BorderLayout.SOUTH);

        frame.add(buttonPanel(), BorderLayout.CENTER);

We then changed the layout manager for the JPanel of buttons to be a BorderLayout:

        private JPanel buttonPanel() {
            JPanel result = new JPanel();
            result.setLayout(new BorderLayout());
            result.add(makeButton("Yellow", Color.YELLOW));
            ...
        }

So we changed this to put the buttons in different areas:

        private JPanel buttonPanel() {
            JPanel result = new JPanel();
            result.add(makeButton("Yellow", Color.YELLOW), BorderLayout.NORTH);
            result.add(makeButton("Blue", Color.BLUE), BorderLayout.SOUTH);
            result.add(makeButton("Red", Color.RED), BorderLayout.EAST);
            result.add(makeButton("Magenta", Color.MAGENTA), BorderLayout.WEST);
            result.add(makeButton("Green", Color.GREEN), BorderLayout.CENTER);
            return result;
        }

• It says to the north and south elements, "What height do you prefer to have?" It then gives them that height. But it sets their width to be the full width available in the panel.

• It says to the east and west elements, "What width do you prefer to have?" It then gives each of them that width. But it sets their height to be the full height available minus the area given to the north and south elements.

• Any extra space is given to the center element. So when the panel is big, the center element is big. When the panel is shrunk down, the center panel is the first to disappear.

I then pointed out that the colored panel is not very tall. Remember that the frame itself has a BorderLayout that is deciding how to lay out the two frame components. So I asked people what this tells you about the colored JPanel. The answer is that it's preferred height is rather small (10 pixels).