PI: Laboratory 4: Calculator - Dispatch and Procedures

• Home
• Mechanics
  
  • Initial Handout
  • Syllabus
  • Learning Objectives
  • People
• Course Text
• Assignments
• Links
• Wiki

Introduction

This assignment emphasizes the following topics:

• Dispatch
• Procedural encapsulation
• Mechanics of execution and control flow, including Threads

This assignment is due at 5pm on Wednesday, October 1st, to the pi-homework mail-in.

Contents

• Introduction
• Pre-Lab
  • Finger exercises
  • Lab Preparation
    • Review the Calculator Interface
    • Review the provided helper methods
    • Design the ButtonHandler controller(s)
    • Draft your code
• Laboratory
  • What to Bring to Lab
  • Getting Started
  • Scaling up
  • Before you leave
• Post-Lab, AKA What To Turn In

Pre-Lab

Lab Preparation

Specifically, you will implement an active object class which will interact with a Calculator object to respond to the user. The Calculator can do such things as figuring out which button the user presses, and managing redrawing, displaying, and other various things that happen on your computer screen. However, it does not actually know how to interpret these button presses, or what answer to display. That is your object's job.

For this lab, you will need to define an active (i.e., animate) object class that will interact with the Calculator object. A particular instance of a Calculator object will be passed to your object's constructor when your object is created (i.e., when you run the Calculator.Main program), so be sure to define an appropriate constructor. Your object must then tell the Calculator exactly what to do, such as recognizing and appropriately responding to the user's button presses.

Q Find a 4-function (or better, but not reverse Polish) calculator. (There is one running under Windows: Accessories>Calculator) Run a few experiments on it. What does it do under various key sequences. Try to think of slightly non-intuitive sequences. E.g., what does it do if you press digit op op digit equals? Run at least four experiments and record their results. If you find it helpful, you may want to record your results in a table of current state vs. next button press.

Reviewing the Calculator Interface

ButtonIDs

These are all static, i.e., accessible as parts of the Calculator interface: e.g., Calculator.OP_ADD. They are also final, i.e., they cannot be changed. Finally, they are all of type int. (Hint: think switch/case.)

All of these constants are distinct from one another and from the numbers 0 through 9; it is intended that the numbers 0 through 9 serve as buttonIDs for their respective buttons.

An additional constant, Calculator.NO_OP, is not a buttonID but is provided for convenience.

QImagine that foo is an int representing one of the ButtonIDs. Write a boolean expression that will be true exactly when foo is one of the arithmetic operation buttons.

ButtonLabels

QWrite a (private) helper method (for possible inclusion in your ButtonHandler logic) that accepts as its single argument an int representing one of the ButtonIDs and returns the String representing the label of that button. Challenge: Can you write the method body in a single line of code? (3-point font is cheating!)

Methods: getText, setText, getButton

public int getButton();

Each Calculator object also has its own getText and setText methods for interacting with the Calculator's display. (Note that the display, and these methods, operate using Strings, not a numeric type such as int.) Their signatures are as follows:

public String getText();

public void setText( String s);

setText replaces any currently displayed text with its single argument, a String.

Reviewing the provided helper methods

We've provided you with a coercion routine which takes a String and returns a floating point (double) decimal number:

double cs101.util.Coerce.StringTodouble( String s);

You can also use Java's built-in routine to do the same thing. It throws NumberFormatException if the string you pass it doesn't represent a double. The signature looks like this:

double Double.parseDouble(String s) throws NumberFormatException;

public int String.indexOf( int ch);

or

public int String.indexOf( String str);

Designing the ButtonHandler controller(s)

As usual, you should follow an incremental design strategy -- keeping the end goal (a working calculator) in mind, but starting with simple implementations first. Before going to lab, think about how you would implement the following:

Implementing Echo

Implementing Reset

Write code that will allow you to reset your calculator. For this purpose, you will probably find it useful to define a reset() method which you can call whenever you want to reset the calculator. Later on, you can then fill the body of reset() with the things you want to do when you reset (i.e., setting fields to their appropriate values). Remember that there is nothing wrong with an object calling its own methods. In fact, methods used in this way can be very useful for grouping commonly used code together, so that instead of rewriting the same code whenever you need it, you can just call the method.

Q How would you make the calculator reset (i.e., call the reset() method you have defined in your class) when then the CLEAR button is pressed, but not at any other time?

Scaling Up

Remember, don't try to implement a complex calculator all at once. Break it down into pieces that you can test independently, and test them thoroughly before moving on to the next step.

At this point, you can now try to design a simple ButtonHandler that accepts only digit op digit =. Any other input should cause the ButtonHandler to reset itself. Map out the logic of this controller. At each step, be explicit about what appears on the Calculator's display. Since the operator does not appear on the display, you may want a place to store it. Be sure that you know where you'll keep each piece of information at each point along the way.

The target exercise is to have a calculator that understands at least digit op digit equals, along with a working clear button.

Extra Stuff

• Reset the calculator when the clear button is pressed.
• Add the ability to handle multi-digit integers.
• Add the ability to handle decimal numbers.
• Make the clear button clear the display instead of resetting the calculator.
• Add the ability to handle op or = in other positions.
• Make the clear button clear the last key pressed.
• Make the clear button clear the last key pressed if pressed once, but clear the entry or reset the calculator if pressed twice.
• Add memory. This will require a revised interface and a revised GUI class to implement, so you should only expect to actually build this if you have time to kill. This requires external storage.

Q Think of examples that your code ought to work on at each stage, as well as examples where it might not behave as you would like. Write these examples down and experiment with them in lab.

Drafting your code

Your code should define a class called ButtonHandler. Its constructor method should take a Calculator as its only argument. Your ButtonHandler should be an active object: it should have its own (activated) Thread. At each point in time, it should gobble up a button press (by calling the Calculator object's getButton() method) and, if appropriate, update the Calculator's display. (It should also update its own internal state at each step.)

Q Write a constructor for your ButtonHandler class. Make sure that it starts its own Thread.

You will almost certainly want to keep your central control loop small. This is best accomplished by spinning off procedures to handle separate cases. By passing parameters, you can make these cases reasonably general. Remember that you don't want to be writing a lot of the same code many times. When this happens, it is a good hint that you've got a common pattern, and it's always a good idea to write down the common pattern, give it a name, and make it into its own method. But make sure that your common pattern makes sense, too. A good rule of thumb is: if you can't explain your code pretty clearly and concisely to someone else, it isn't designed right.

Details of the ButtonHandler specification, as well as hints for a stage-by-stage implementation, are given in the Laboratory section, below. Roughly speaking, it follows these steps:

1. Implement ButtonHandler as an active object type, but with minimal logic.
2. Build a simple logic into your code.
3. Expand your code in pieces, one step at a time, working with and not against your abstractions.

Laboratory

What to Bring to Lab

• Bring answers to all of the questions marked with a Q above.
• Also bring a development plan, listing at least 3 stages of code:
  1. minimal code that will compile
  2. code that echoes the buttons clicked to the display
  3. a third stage which is a reasonable next step (not too big)
  You do not need to have the whole code, but an English description of what the code accomplishes and how. You should also include a test that each stage will pass and a test that each stage will fail.

Getting Started

When you begin to code, even though you may have constructed a sophisticated design for your ButtonHandler, you should always begin your lab-work with a simple, independently testable implementation and build on it as each stage works robustly.

For example, start with a very simple class with just a constructor that takes a Calculator as its only argument, and make sure that it compiles. Then, you can begin testing your class design, without any of the internal logic. Although it makes a pretty lousy calculator, a simple test that will help ensure that your infrastructure is working is to simply echo each button pressed back to its Calculator's screen.

Compile and run your code to make sure that you've built things correctly. If you have problems, now is a good time to work them out.

Scaling up

The target exercise is to have a calculator that understands digit op digit equals, along with a working clear button.

Remember that we think it's better to produce basic but elegant, well-tested, well-documented, and well-understood code than code with additional features but poorly written/documented/tested. We are more interested in how well you do what you do than in how much you do."

Record your experiences, including tests that various stages of your implementation succeed and fail. Make sure that you understand how your code behaves, and how it will behave under inappropriate as well as appropriate circumstances.

Before you leave

Post-Lab, AKA What To Turn In

• on the front page, how much out-of-class time (approximately) you've spent on reading, on preparation of the homework, in lab, and on other non-class-time course-related activities (and what). These times should include work from last Wednesday 5pm to this Wednesday at 5pm
• your pre-lab assignment, including answers to the questions and your development plan
• your code, including its documentation, and a description of its functionality.
• your observations concerning
  • the calculator logic development process,
  • the coding/debugging process,
  • the behavior and reliability of your code.
• a brief description of the check-off interaction, and answers to any specific issues s/he may have asked you to address.
• the names and roles of any collaborators in any parts of the project.
• We've experimented with a couple of different class formats.
  • Are there formats that have worked out well or poorly?
  • Any suggestions for improving the delivery of material in class