Homework 3

Everyone’s design project 1 implementation should have a “Gesture” hierarchy (wether you called it Gesture or not, doesn’t matter) and a “Scoring” hierarchy. Many of you also have a Player or “hand” object. For homework 3, you must implement the Observer pattern so that your Player object notifies the Scoring object when it has chosen a gesture.

In other words, you will add GestureSubject and GestureObserver interfaces to your design, and modify the appropriate classes in your design to implement them.

If you do not have a Player (or similar) object in your design already, you should add that as well. The Player object for this homework does not need to be as described in the original DP1 Extra Credit section; it simply needs to be a class with a “getGesture()” method, that causes that player to choose a gesture (either randomly for computer-generated choices, or via console interaction for human-generated choices).

Provide one or more test cases where several player objects are created. “getGesture” should be called on each player, which in turn would notify the Scoring object (the observer, properly registered of course) of its choice. Your test case should assert that the scoring object can decide the correct winner after having been notified of the player choices.

Due: Friday Nov 2. Office hours by e-mail or appointment only.

UPDATE: To submit, you must create a branch of your design project 1, and implement the changes in that branch. Instructions to follow shortly!!

“Project 1″ vs “Design Project 1″

So I screwed up the naming of these things. To differentiate between “10%” projects and “15%” projects, we’ll use “Project” vs “Design Project” respectively.

To be clear, so far:


EE363 Design Project 1 – Design Notes

Here’s a couple notes regarding design project 1

  • Your object model must represent Rock, Paper, Scissor, Lizard, Spock, Radioactive, Poisonous and Infested as objects under a common “Gesture” base type

    A Gesture must have a method called: getName() that returns the name of the gesture, for example: “Radioactive Spock”, or “Infested Paper”.

  • Your scoring implementations can check to see what kind of object a Gesture is by looking at it’s name, like so (this is just an example of something you might do… my reference implementation, for instance, has no such method…):
public boolean isSpock(Gesture g1) {
    return g1.getName().contains( "Spock" );

More updates may come as we go through office hours… stay tuned.

EE363 Design Project 1

Here is EE363 Design Project 1: Rock, Paper, Scissors, Lizard, Spock; Radioactive, Poisonous, Infested edition!

Update Posted on Thurs Sep 13:  http://www.timfanelli.com/2012/09/ee363-design-project-1-design-notes/

It is due Friday, September 28, 2012. All the details are in the PDF. Here are a few key bullet points:

  • Work in teams of two to three people. Notify me of your teams by class on Friday, so that I can get the SVN repositories set up over the weekend.
  • Office hours are 12-2p M/W/F, or any time by appointment (please give me at least 1 day heads-up making appointments by email).
    * The entire team must be present at office hours
    * You must bring UML to office hours, or I will ask you to leave.
  • You must, must, must utilize the design patterns and principles learned this semester!

This project is worth 15% of your grade.

BigDecimal, RoundingMode, and currency values in Java

So admittedly Monday’s discussion on BigDecimal was a fiasco. Here’s a quick attempt to clean it up, and clarify usage of BigDecimal for representing currency values in our Pizza implementations.

Consider the following test case, given the Beverage Decorator implementation from Chapter 3:

public class BigDecimalTest {
 public void testBigDecimal() {
    Beverage b = new Beverage();
    b.setCost( new BigDecimal( "4.99" ) );
    b = new Mocha( b, new BigDecimal( "0.49" ) );

    // Apply a hypothetical 7.25% sales tax...
    MathContext mc = 
       new MathContext(3, RoundingMode.HALF_UP);
    BigDecimal tax = new BigDecimal( "1.0725" );
    BigDecimal cost = b.getCost().multiply( tax, mc );

    Assert.assertEquals( "Cost is not as expected.", 
        new BigDecimal("5.88"), 
        cost );

The test case a beverage with base cost of $4.99, and wraps it in a Mocha decorator at $0.49 for a total cost of $5.48. It then applies a hypothetical sales tax of 7.25%.

The math will work like this:
$5.48 + 7.25% = $5.8773

Of course, since we only work in whole-pennies, we round up to $5.88 even. This is asserted in our test case, which passes successfully.

The magic to make this happen is as follows:

  1. The BigDecimal instances are constructor using the string representation of the numeric value. This avoids any IEEE floating point issues (when we omit the quotes, the number is interpreted as an IEEE double value by the compiler, potentially introducing error)
  2. We utilize a MathContext on the arithmetic operation (multiply). This enforces a precision of 3 with a rounding mode of HALF_UP.

You might expect (as I did on Monday) to use a precision of 2, not 3; however, when the result is rounded, the least significant digit is lost. So if I specify a precision of 2, the hundredth’s digit is dropped on rounding; specifying a precision of 3, I lose the thousandth’s digit and get a result back to whole-penny value.

I could also give the MathContext to each BigDecimal I construct, however, in this instance there is no need. Since the “add” operation has no risk of introducing additional precision, there is no requirement for rounding until I apply the hypothetical tax.

So the short version is this: when you construct your BigDecimal objects, do so using the constructor that takes a String argument, as Kasa recommended in class on Monday. We’ll add a “TaxCalculator” requirement to the Pizza store to exercise the need for RoundingMode and MathContext, but will only utilize it in our unit test scenarios.

Reference materials: