Fig. 11.

1 The
model–view–controller
architecture
 Benefits of the MVC Pattern

1. Cohesive modules: Instead of putting unrelated code (display and data) in the
same module, we separate the functionality so that each module is cohesive.

2. Flexibility: The model is unaware of the exact nature of the view or controller it
is working with.

3. Low coupling: Modularity of the design improves the chances that components
can be swapped in and out as the user or programmer desires

4. Adaptable modules: Components can be changed with less interference to the

rest of the system.

5. Distributed systems: Since the modules are separated, it is possible that the three
subsystems are geographically separated.
 Analysing a Simple Drawing Program

We now apply the MVC architectural pattern to the process of designing a simple program
that allows us to create and label figures. The purpose behind this exercise is twofold:

1.To demonstrate how to design with an architecture in mind Designing with an architecture
in mind requires that we start with a high-level decomposition of responsibilities across the
subsystems.

2. The subsystems are specified by the architecture. The designer gets to decide which
classes to create for each subsystem, but the the responsibilities associated with these classes
must be consistent with the purpose of the subsystem.

3. To understand how the MVC architecture is employed We shall follow the architecture
somewhat strictly, i.e., we will try to have three clearly delineated subsystems for Model,
View, and Controller.
 Specifying the Requirements

Our initial wish-list calls for software that can do the following.

1.Draw lines and circles.

2. Place labels at various points on the figure; the labels are strings. A separate
command allows the user to select the font and font size.

3. Save the completed figure to a file. We can open a file containing a figure and
edit it.

4. Backtrack our drawing process by undoing recent operations.

In order to attain this functionality, the software will interact with the user. We need to specify
exactly how this interaction will take place.

Without more ado, let us adopt the following ‘look and feel:

1.The software will have a simple frame with a display panel on which the figure will be
displayed, and a command panel containing the buttons. There will be buttons for each
operation, which are labeled like Draw Line, Draw Circle, Add Label, etc.

2. The display panel will have a cross-hair cursor for specifying points and a_ (underscore) for
showing the character insertion point for labels.

3. The cursor changes when an operation is selected from the command menu. When an
operation is completed, the cursor goes back to the default state.

4. To draw a line, the user will specify the end points of the line with mouse-clicks. To draw a
circle, the user will specify two diametrically opposite points on the perimeter.
Defining the Use Cases
 Designing the System

•Our architecture specifies three principal subsystems, viz., the Model, the View and the
Controller. We have a broad idea of what roles each of these play, and our first step is to
define these roles in the context of our problem.

Defining the Model

* This is relatively simple for our problem; we keep a collection of line, circle, and label
objects.

* Each line is represented by the end points, and each circle is represented by the X-
coordinates of the leftmost and rightmost points and the Y -coordinates of the top and
bottom points on the perimeter

Defining the Controller

* When the user attempts to execute an operation, the input is received by the view. The
view then communicates this to the controller.

* This communication can be effected by invoking the public methods of the controller
Drawing a Line
* The user starts by clicking the Draw line button, and in response, the system
changes the cursor.

•Clearly, changing the cursor should be a responsibility of the view, since that is
where we define the look and feel. This would imply that the view system (or some
part thereof) listen to the button click.

•The click indicates that the user has initiated an operation that would change the
model. Since such operations have to be orchestrated through the controller, .
2. The user clicks on the display panel to indicate the first end point of the line. We
now need to designate a listener for the mouse clicks.

This listener will extract the coordinates from the event and take the necessary action.
Both the view and the controller are aware of the fact that a line drawing operation has
been initiated.
Drawing a Circle
The actions for drawing a circle are similar. However, we now have some additional
processing to be done, i.e., the given points on the diameter must be converted to the
the four integer values.

Adding a Label

1. The user starts by clicking the Add Label button. In response, the system
changes the mouse-cursor, which, as before is the responsibility of the view.
2. The user clicks the mouse, and the system acknowledges the receipt of the
mouse click by placing a_ at the location
3. The user types in a character
4. The user clicks the mouse or enters a carriage-return.
 Item and Its Subclasses
The includes method is used to check if a given point selects
the item. The Line class looks something like this:

public class Line extends Item {

private Point point1;
private Point point2;
public Line(Point point1, Point point2) {
this.point1 = point1;
this.point2 = point2;
}
public Line(Point point1) {
this.point1 = point1;
}
public Line() {
}
public boolean includes(Point point) {
return ((distance(point, point1 ) < 10.0) || (distance(point, point2)
< 10.0));
}
public void render() {
uiContext.draw(this);
}
// setters and getters for the two points
}
 Implementation of the Model Class
public class Model extends Observable {
private Vector itemList;
private Vector selectedList;
public Model() {
itemList = new Vector();
selectedList = new Vector();
}
// other methods
}

Implementation of the Controller Class

public void makeLine() {
makeLine(null, null);
pointCount = 0;
}
public void makeLine(Point point) {
makeLine(point, null);
pointCount = 1;
}
public void makeLine(Point point1, Point point2) {
line = new Line(point1, point2);
pointCount = 2;
model.addItem(line);
}
The Driver Program
The driver program sets up the model. In our implementation the controller is
independent of the UI technology, so it can work with any view.

public class DrawingProgram {

public static void main(String[] args){
Model model = new Model();
Controller.setModel(model);
Controller controller = new Controller();
View.setController(controller);
View.setModel(model);
View view = new View();
model.addObserver(view);
view.show();
}
}
 Implementing the Undo Operation
In the context of implementing the undo operation, a few issues need to be highlighted.
•Single-level undo versus multiple-level undo
•Undo and redo are unlike the other operations
•Not all things are undoable
•Blocking further undo/redo operations
•Solution should be efficient

Keeping these issues in mind, a simple scheme for implementing undo could be
something like this:

1. Create a stack for storing the history of the operations.

2. For each operation, define a data class that will store the information necessary
to undo the operation.
3. Implement code so that whenever any operation is carried out, the relevant
information
is packed into the associated data object and pushed onto the stack.
4. Implement an undo method in the controller that simply pops the stack, decodes
the popped data object and invokes the appropriate method to extract the information
and perform the task of undoing the operation.