6.096 Fall 1997
Introduction to Interactive Programming

Documentation Project Solutions

The Assignment

What you will actually turn in is a set of documentation for this software. The documentation that you provide comes in two parts.

The first part is documentation for the code itself. In documenting the code, you should follow the conventions of the Design Project:

It should be possible to read your documentation and understand what the code is doing -- and why -- almost without reading the code itself.

You may wish to edit the code files that we have provided directly, i.e., to write your documentation as comments in the file.


In additon to the documentation of the code, you should write an overview/design document of 1-3 (typewritten) pages that describes how the code works. This need not address the specific implementations of particular methods, but instead should give a higher-level description of how the various pieces of code interact. This document should, for example, include sufficient information that it would be possible to figure out which piece(s) of code to look at/modify if we wanted to add unary minus (negative numbers), exponentiation, or some other functionality. (You should not explicitly address these questions; this is just to give you a sense of the purpose of this document.)

In writing up this documentation, you should answer the following questions (among others):

There are five major types of objects in this system: Calculator, CalcTextGUI, CalculatorState, ButtonObj, and ButtonHandler. The program runs as follows:

At the start, ButtonHandler receives a Calculator object from the system through the constructor. Inside the constructor, it creates exactly one CalcTextGUI, and one CalculatorState object. It then creates a number of different ButtonObj objects passing the CalcTextGUI and CalculatorState objects to them through their constructors. A separate ButtonObj is created for each button. (Each of the numeric buttons, '0' to '9', for example, get their own NumButtonObj, but each initialized with the appropriate number.) These buttons are stored in buttonObjs, an array of ButtonObj, under their corresponding indices. For example, an instance of ClearButtonObj is stored in buttonObjs[Calculator.CLEAR]. At the end of the constructor, the Thread spirit is created and started. This Thread then starts executing run().

Inside run(), we have a while( true ) loop that gets the next input pressed by calling the Calculator object's getButton() method, and then effectively switches on the input received. This is similar to the "event-driven" implementation discussed in the Calculator lab solutions. Unlike the Calculator solutions, however, the "switch"ing here is done in an unsual way. Instead of using switch or if, we simply call
(where buttonID is the button pressed) to call the handleButton() of the appropriate ButtonObj object. Since each of these objects implements handleButton() differently depending on what particular subclass of ButtonObj they are, we can get different behaviors in much the same way that we got different behaviors by calling different handle...() methods in the Calculator lab solutions. Polymorphism is neat, huh?

For more information on the details of the different classes, please refer to the javadoc documentation, and of course, to the documented source code.

This course is a part of Lynn Andrea Stein's Rethinking CS101 project at the MIT AI Lab and the Department of Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Questions or comments:


Last modified: Tue Oct 7 21:56:59 1997