For example, consider the expression 2 + 3 * 4. The calculator must evaluate this as 2+(3*4), resulting in 14. If all four operators had the same precedence this expression would be interpreted as (2+3)*4, resulting in 20.
Operators of equal precedence are evaluated from "left to right", or in the order in which they are entered into the calculator. Thus, 1-2-3*4/5+6*7 is interpreted as ((1-2)-((3*4)/5))+(6*7), or in a tree form:
+
/ \
/ \
/ \
/ \
- *
/ \ / \
/ \ / \
- / 6 7
/\ /\
/ \ / \
1 2 * 5
/\
/ \
3 4
This is called an expression tree. In our examples interior nodes are operators and leaf nodes are numbers. The structure of the tree shows the intended grouping for the expression.
Recall that the purpose of this project is to review material from CSE115 and to prepare you for the main project of CSE116. For the project to serve its intended purpose (and for you to score well on your submission) you must use design patterns wherever appropriate. You must not use any conditional statements (such as if statements) or loops (such as while loops) in your code. They are not needed. Use polymorphic dispatch to select based on type. Note that the description below is not exhaustive in its detail. You must exercise your analysis skills. You must also ask questions if you are uncertain about what approach to follow.
The calculator must be designed with a Model-View-Controller architecture. This means that you must separate the Graphical User Interface (the view) from the part of the calculator which actually does the computation (the model). The controller mediates the interaction between the model and the view. Here's a description from Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC), written by Steve Burbeck.
In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task. The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
Note that the model, the view and the controller need not directly correspond to single classes. Several classes may define each.
Now consider the operation of the calculator. Notice that pressing a given key does not always do the same thing. Consider what might happen when you first start using the calculator. Pressing a digit key causes that digit to appear in the display. Pressing another digit causes it to appear in the display to the right of the first digit pressed. Pressing yet another digit causes it to appear in the display to the right of the first two digits pressed, and so on. For example, if the digit keys '5', '3' and '7' are pressed in that order, the display will show "537". As long as digit keys are pressed when the calculator is in this state, the corresponding digits are added to the right of the number being formed in the display.
What happens if a function key, such as '+', is pressed next? Does the display change? No. What happens if a digit key is pressed after a function key is pressed? Is another digit added to the current number in the display? No. Instead we start forming another number, the second argument of the operation.
Suppose we enter the number 13 by pressing '1' and then '3', and then press some non-digit key. The behavior of the calculator will depend on which key is pressed. If '=' is pressed, the expression must be evaluated (producing 550), and the state of the calculator is reset to its initial state. This means that if a new number is entered, it will be the first argument of the next operator.
If, on the other hand, the '-' is pressed (or '+' since these operators are of equal precedence), the expression must be evaluated (producing 550), but the result itself becomes the first argument of '-'.
Suppose that '*' (or '/') is pressed after the 13 is entered. Instead of evaluating 537+13, since '*' has higher precedence than '+' 13 becomes the first argument of '*'.
Whenever the 'C' key is pressed, the display is set to zero and the calculator is set to its initial state. Any pending operations are "forgotten".
You now have enough information to determine how the calculator is to function. However, like any real-world software development scenario you may still have questions, and it is possible that this description is underspecified (meaning there might be more than one way to interpret the problem). If (when) you have questions, do ask! You should ask general questions about the project in the newsgroup.
You must build the complete calculator, including the GUI. The GUI must have a display and the buttons indicated above. Nothing fancy is required, but the layout should at least be close to what you see in a typical calculator. You are required to use NGP for this project. (When you get to working on the GUI for the semester-long project, you will not be permitted to use NGP, but now is not the time to tackle the added complexity of AWT/Swing graphics.)
This project is due on or before 11:59 PM on February 2, 2004. Recall the early bonuses and late penalties outlined in the syllabus, handed out on the first day of classes. Projects submitted on or before 11:59 PM on February 1, 2004 are considered one day early, and projects submitted on or before 11:59 PM on January 31, 2004 are considered two days early. Projects submitted after 11:59 PM on February 2, 2004 are considered late.