Session 11

Implementation of MVC

810:171

Software Systems

Exercise 16: How Objects Can Watch One Another

Goals

1. To understand better how changes can propagate among objects.
2. To begin to think about how to implement MVC in a program.

Tasks

Work in teams of three or four people based on the number assigned in class. Together, study the code in the handout. and do the following tasks.

1. Determine what the output of the program is.

2. Describe how you could use this sort of mechanism to implement a set of generic MVC classes. Sketch a simple design of the classes, with as much detail as possible about where the various elements of this program would reside in your solution.

3. Develop a list of questions about the code, focusing especially on how the program's function relates to the Model-View-Controller pattern. You may also comment and ask about the content and style of the program.

Feel free to use the MVC paper you read last week as a source of ideas.

Results

Your group submits a page showing your answer from the main program, with any drawings or scratch work that support your answer; your list of questions; and your proposed MVC design.

We will discuss your questions and try to provide answers.

Summary from Exercise 16

Here are some of the questions I answered as I moved around the groups:

What is this? It is a Java and C++ "pseudo-variable" that refers to the object that is responding to the message. In this example, a reactor passes this to its dependents with an update message, so that the dependent knows who is sending the update message.

What do the first three lines of the reactor constructor do? They initialize the instance variable my_name, a string, to the value of the constructor's argument, name.

What if the object needs to update itself differently depending on who send the update message? This is precisely why the sender of update passes itself as an argument with the message -- so that the receiver can use that information, if it wants, when updating. In this example, a reactor displays the name of whoever asked it to update.

How do we avoid an infinite loop of dependents? In MVC, this tends not to be a major problem, since most dependencies run from views to models. In general, though, this is a thorny problem. A number of algorithms address this problem in specific circumstances. You will learn about such algorithms in 810:153 and 810:161.

Isn't there a better way to handle subscription overflow? Sure. This is just a demo program. (The Ada'95 demo program throws an exception; the Java, C++, and CLOS demos could do the same.)

Exercise 17: A Simple Model-View-Controller (MVC) Implementation

Goals

1. To understand better how MVC works, using a simple text-based system.

Tasks

Work in the same groups as you did for Exercise 16. Together, study the code in the handout and do the following tasks.

1. Determine what the output of the program is.

2. Develop a list of questions about the code, focusing especially on how the program's implementation of the Model-View-Controller pattern. You may also want to comment on the style of the program.

3. Add comments to the files that you think improve the readability of the program. Write your comments directly on one of the printouts I gave you.

4. Develop a list of any other improvements that you would make to the code.

Feel free to use the MVC paper you read last week as a source of ideas.

Results

Your group submits a page showing your answer from the main program, with any drawings or scratch work that support your answer; your list of questions; and your list of proposed improvements. You also submit your commented version of the code.

We will discuss your questions and try to provide answers.