Lab 8 Commanding Calculators

This is an individual lab.

Most students are used to calculators which have parentheses so users can control the order of operations. For example, you might enter 3 * (4 + 5) to compute 23. An alternative that was popular decades ago was to use RPN which allowed you to enter the numbers and then apply operations. The HP-35 was one such calculator. See this HP-35 emulator. To use it, click on the 3, ENTER↑, 4, ENTER↑, 5, ×, +, and notice the calculator displays 23.

You are being given an implementation of a similar calculator. For most students, you will get the code through GitHub Classroom, but this code is also available in the file calculator.zip. While this calculator uses RPN, it has other key differences from the HP-35. You will not attempt to emulate the HP-35. Instead, you will extend the provided calculator so it supports undo and redo through the Command pattern.

To get started, check out (or download) the code and open the project in IntelliJ. Attempt to build CalculatorTest. If you have errors saying "package org.junit does not exist", then open CalculatorTest.java (in IntelliJ) and select "Add 'JUnit4' to classpath". This will cause IntelliJ to prompt you to download the library from the Maven Repository; click OK. Once built, right click on CalculatorTest in the project browser and execute all of the tests. These test just the basic calculator operations; they do not test undo and redo. You will test those in other ways.

Once the built-in tests are working, confirm that your calculator works through the console. Run the program and enter the bold-face text as shown below:

           4,5*

      Display: 4
      Multiply
      Display: 20

           q

      Quit
      Final result: 20

To compute "(18 - 3) * 2", enter

      18,3-2*q

Note the comma (,) roughly corresponds to the "ENTER↑" command on the HP-35; it signals that a complete number has been entered. A significant difference between this calculator and the HP-35 is that as values are computed, they are placed in an accumulator rather than on a stack. An operation such as add takes the current accumulator and the displayed value, adds them, displays the value, and stores that value in the accumulator. Thus if you enter **3,4,5* **, the calculator will replace the 3 by a 4 after the second comma, and the final result will be 20.

So you have an idea of where you are headed, the following shows what happens if the user decides to add instead of subtract and then goes on to do other operations:

           18,3–2*

      Display: 18
      Subtract
      Display: 15
      Multiply
      Display: 30

           u

      Undo
      Display: 2

           u

      Undo
      Display: 15

           u

      Undo
      Display: 3

           +

      Add
      Display: 21

           2
           *

      Multiply
      Display: 42

           q

      Quit
      Final result: 42

Note that undoing the multiply (after displaying 30) results in displaying a 2 in the middle of this run; that is so the user knows what number (in this case, a 2) is being applied to the accumulator. This is the behavior you would probably see on a real calculator if that calculator supported undo and redo. If you would like to see a bit more explanation of this example, you might check out a video illustrating it.

Detailed Requirements

• See Main.java for the list of commands and their effects. The commands echo to the screen; on a real calculator, these would be replaced by (say) lights that show particular operations have been executed. Several of your changes will be in Main.java.
• Add 'u' to undo the previous action and 'd' to redo it. Only allow undoing actions if there is an action to undo, and only allow redoing actions if there is an action to redo. If no actions are available for either one, display "Nothing to undo" or "Nothing to redo". After executing an action, display the new state of the calculator.
• You could support undo by storing the complete state of the calculator before each action. This would be unrealistic because the extra storage this would require would reduce battery life. On the other hand, if you try to store an absolutely minimal state, it can be difficult to ensure correctness. Work towards a middle ground between storing too much and too little.
• History.java is the History class from the phonebook example with class Command renamed to CalculatorCommand. You should not need to make any changes to History.java or CalculatorCommand.
• After undoing any operation except appendDigit, the calculator should be in the state that allows new numbers to be entered (newNumber should be true). That is, undoing most operations means that the next digit starts a new number. Undoing appendDigit should leave the next digit state as it was before the appendDigit command was executed. That is, appendDigit will need to save and restore Calculator.newNumber.
• For consistency with the other operations, the 'u' key will print "Undo" and the 'd' key will print "Redo". If there is no command to undo or redo, print (as appropriate) No commands to undo. or No commands to redo.

How to get started

1. Start by getting the calculator tests to pass. You should not need to write any code, but you may need to refine your project setup.
2. Implement the execute and unexecute for the add command. The execute operation will be very similar to the code that is in Main.java, and implementing unexecute will boil down to figuring out what data to save in execute and restoring the appropriate items in the unexecute.
3. Revise Main.java to use the add command rather than simply adding values. Make sure you can handle an input sequence like 3,4+ud.
4. Implement the other operations (-, *, /) in the same way, and test this portion.
5. Implement the remainder of the system.

Submitting

• Check on Canvas (or wherever appropriate) for directions for submitting your work. Note that you must make no changes to Calculator.java. You may also need to submit responses to various questions.
• Do double-check that your final version has no extra prompts or debug output.
• Make sure your final submission satisfies your instructor's coding standard. In particular, be sure to document any classes you write (including those we started for you). You do not need to document abstract methods when the base class already has accurate documentation. You may also need to format the code so the indentation is consistent.

Test Data

The data used for testing (inputs and outputs) is available as test_data.zip