Application Objective Task 1

Time Estimate: 8 hours
Jump to current week
Requirements

Introduction

You will write a 4 function calculator without using any control flow, meaning you cannot write any code that will be executed conditionally. Instead, you will apply object-orientation programming approaches to make decisions based on types instead of values. Specifically, you are expected to use the state pattern to complete this assignment.

The following are banned in your submissions:

  • Conditionals
    • if/else if/else
    • switch/case
    • throw/try/catch/finally (Can be used to simulate conditionals)
  • Loops
    • for
    • while
    • do/while
  • Any way of directly simulating Conditionals or Loops that is against the spirit of this assignment. (Ex. Taking advantage of short circuit evaluations)

If your submission, including your tests, contains any of the keywords listed above, it will not be graded.


Project Structure

GitHub Repository link: https://github.com/jessehartloff/AO2

  1. Clone the starter code from the repository into a new IntelliJ project

You can run the calculator.view.CalculatorGUI class to see the provided GUI. Your goal is to add functionality to this GUI by implementing the calculator.model.Calculator class. Do not edit any code in the view or controller packages. You have full control over the model package and this is where you will write all of your code. You may add any methods, variables, objects, classes, interfaces, or sub-packages you’d like to complete the objectives. All testing, including your tests, will only access the calculator.model.Calculator class and will only call methods provided in the Calculator class. You may add more methods/variables/classes/etc, but do not access them from your tests since they will not exist in my solutions on Autolab.


First Application Objective - Basic Features

Test and implement basic functionality for your calculator to earn the first application objective

Testing Requirements

Test the following features of your calculator.model.Calculator class. In your tests, only call the methods that are provided in the handout code as any other methods.variables.classes won't exist in the solutions and will cause errors in Autolab. You will call the various "pressed" methods to simulate pressing buttons on the calculator, then call displayNumber and assert that it returns the expected value.

For this application objective, test the following functionality in the tests.TestCalculator class:

  • The calculator initially displays 0.0
  • Pressing the number buttons will append that number to the end of the displayed number. For this objective, you may assume all the numbers entered will be whole numbers (ie. the decimal button will never be pressed when testing for the first application objective). For example, starting the calculator and pressing [4, 6, then 1] should result in displayNumber() returning 461.0. When testing the number buttons, only call the numberPressed method with an input in the range 0-9. These are the only inputs that the GUI can call the method with and all others should be considered invalid and should not be tested
  • Test the 4 operator buttons (+, -, *, /). The user can enter a number (With any number of digits), press an operator button, enter another number (With any number of digits), then press equals and the displayed number should be the result of the operation. Ex. If the user presses [2, 5, /, 5, =], displayNumber() should return 5.0
  • After pressing =, another operation can be entered which will use the result of the previous operation as its left hand side value Ex. [2, 0, +, 1, 5, =, /, 1, 0, =] results in 3.5 being displayed. [3, +, 4, =, *, 2, =] results in 14.0 being displayed

You'll need to append digits to the end of numbers and also display them as Doubles. It can help to store the numbers as both Strings and doubles to build this functionality. When a digit is pressed, concatenate the digit to the end of the String, then convert the String to a double and store this separately for the displayNumber method. (Or convert the String to a double in the displayNumber method)


Programming Requirements

Implement the tested functionality without using any control flow


Second Application Objective - Advance Features

Test and implement advanced functionality for your calculator to earn the second application objective

Testing Requirements

For this application objective, test the following functionality in the tests.TestCalculator class:

  • The clear button returns the calculator to it's initial state with 0.0 being displayed
  • Test the decimal button allowing for floating point inputs. The first time the decimal button is pressed when number is being entered will determine where the decimal point will be placed. All subsequent presses of the decimal button for that same number will have no effect. Ex. [1, 2, ., ., 5, ., ., 0, ., 5] should display 12.505
  • Entering decimal as the first button when entering a number will have 0 as its whole number portion Ex. [., 5] results in 0.5 being displayed
  • Pressing equals multiple times in a row will repeat the previous operation Ex. [8, 0, -, 1, 0, =, =, =, =] results in 40.0 being displayed
Programming Requirements

Implement the tested functionality without using any control flow


Undefined behaviour

To limit the complexity of this assignment there are certain sequences of button presses that have undefined behaviour. These sequences will not be tested in Autolab and you must not test these sequences in your tests since the expected number to be displayed is undefined. Do not test any of the following:

  • Only pressing the decimal button when entering a number Ex. [., +, 1, =], [6, *, ., =]
  • Pressing consecutive operator buttons Ex. [2, 5, /, *, 5, =]
  • Pressing an operator or equals before entering a number Ex. [+, 1, 1, 6, =] or [5, 5, +, =]
  • Pressing another operator button before pressing = Ex. [2, 5, /, 5, +, 7, =]
  • Pressing a number button after equals Ex [2, +, 2, =, 4]
  • The value that's displayed after an operator button is pressed, but before = is pressed. Ex. The only time you should test the returned value of displayNumber is when the first number is being entered or immediately after the = button is pressed