A Java Course Module featuring:

• The user interface may be changed without affecting the logic of the code
• A single application may be equipped with multiple interfaces.

Introduction

• Only 2 operands allowed per operation;
• Only the 4 basic operations considered;
• Only integer operands considered.

Web Resources

• The Calculator has been implemented using two different GUI interfaces:
• Interface 1:
• The user types in the two operands in two textboxes;
• Clicks on one of the four operation buttons;
• Result is displayed in a label at the bottom.
Click here for:
• The source code  (interface1/calc.java)
• The running demo  (interface1/calc.html)
• Interface 2:
• The user enters the operands by pressing buttons;
• Clicks on one of the four operation buttons (after entering the first and before entering the second operand), and = button at the end;
• Result is displayed in a label at the top.
Click here for:
• The source code  (interface2/calc.java)
• The running demo  (interface2/calc.html)
• Now, the calculator is reimplemented with MVC, such that the above two interfaces are both run off the same model:
• The model, i.e., the calculator logic is in calcModel.class
• The second interface is implemented in two classes:
• viewButton class - for the View
• controlButton class - for the Controller
The Model, View and Controller are brought together in MVC class. Click here for a demo.
• The first interface is again implemented in two classes with the same model:
• viewText class - for the View
• controlText class - for the Controller
The Model, View and Controller are brought together in MVC2 class. Click here for a demo.

• Analysis & Simulation: They may be encouraged to form teams of 3. Each student studies one of model, view and controller. They can then role-play these components to understand how exactly they are coordinated:

• how the model extends Observable; how it declares control as the actionlistener of view;
• how the view implements Observer, how it calls only the selector methods of the model to update the display
• how the controller implements actionlistener, how it calls the mutator methods of the model to update it, how it notifies Observer.
They could use post-it notes as methods, and each maintain a notepad to depict their current state.
• Reverse Engineering: Students may be asked to study the difference between the code without MVC and the code with MVC with an eye towards summarizing the steps needed to convert from the first to the second. Does this involve major re-writing of code, or is it just re-arranging existing code?  Such conversion is a useful exercise since students may find MVC overwhelming and may welcome the idea of writing the code without MVC first, and converting it to MVC later. It is my personal experience, that this conversion exercise can be rewarding and instructive.
• Concept Formation: How can one identify the segments of an problem/existing program that go into each of model, view and controller? This is a conceptual exercise. Students may be asked to write pseudocode in MVC for a problem, clearly identifying the three components in a problem statement.

Lecture Outline

1. Introduction to the Java event handler, and at least TextField, Button, Label, and Panel components
2. Introduction to patterns
3. The MVC pattern, and its advantages, that MVC is a major motivation for Java Swing classes, and how this puts "problem solving" back into programming!

In-Class Exercises

• Analysis & Simulation exercise listed earlier could be used in class.
• Students could be asked to write code for a simple MVC breakdown of a Java component, such as the self-changing button in this demo. (Click here for model, view,  controller and the MVC class.)
• Students could be asked to analyze the model, view and controller components of a sample problem.

Take-Home Exercises

• In the viewButton/controlButton implementation of calculator:
• Does the calculator function properly when the result is 0? If not, fix it.
• Add functionality of Plus/Minus button;
• Add the functionality of disabling buttons as follows:
•   +, -, * and / buttons should be enabled only after at least one non-zero digit is entered for operand1
•   = button should be enabled only after at least one non-zero digit is entered for operand2
•   Plus/Minus should be enabled only after at least one non-zero digit is entered for either operand, and should be disabled at all other times
• Add a clear button
• Should the method appendOperand() be in the model or the controller?
• Add other functionality to the calculator in both versions and interfaces:
• Functions such as memory adding, square root, average, standard deviation, logarithms, trigonometric functions
• Extend the calculator to handle real numbers
• Extend the calculator to handle concatenated expressions, i.e., expressions with more than one operator (assuming evaluation in the order of operator entry rather than any precedence rules).
• Rewrite the calculator MVC implementation using Java Swing classes. Document the improvements in Swing classes that make MVC implementation of a program easier.
• Bug report: In the viewText/controlText implementation of calculator: the user must type the first operand in the first textfield and hit enter BEFORE typing the second operand in the second textfield; the user must hit enter after typing each operand. Fix this bug (or "feature" if you will :)

Pedagogical Patterns:

• Lay of the Land - of MVC
• Fixer Upper - many bugs in design must be worked out
• Fill in the Blanks - students can extend this project to include more functionality, a little at a time