IC211: Casino Royale ... Object Oreiented Design

Overview

The purpose of this lab is to get experience with Object Oriented Design. We will see how planning out our program with the high-level view of the Class Dependency Diagram, as we discussed in the previous class, allows us to code following a meaningful blueprint. We will also see how starting out with stubbed out classes, which are sort of skeletons that contain the public methods we plan on providing (and nothing else), but with "dummy implementations", which we'll say more about later.

It is our sincere hope that the days of starting a program by sitting in front of the keyboard and banging out code will be over after today, and that you will instead start with a sheet of paper or a whiteboard and start thinking about what classes you need, what methods they'll have, and what the dependencies between classes are.

Important! you will do this lab in groups of three (or two, depending on your class size modulo three). Form your group and choose one member as the "Gold partner".

Setup

The Gold partner will create a project repository named "casino211"on their github account. So, only the gold partner will do the following:

login to your github account
click on the "repositories" tab (top left-ish) and click on the green "New" button (top right-ish) and fill in with:
- Repository name: casino211
- Select "Private" (lock icon)
- Check the "Add a README file" checkbox
Then click on the "Create Repository" button. Voila: you have now created a project!
Click on "Settings", then click on "Collaborators". [Note: you will be prompted to enter your password again.] Click on the "Add People" button, and enter either the usernames or the email addresses the other partners used for their github account, click on their identities and click the "Add name to this repository" button.
Other partners: go to your email and accept this invitation.

Both Partners: On your separate lab machines, pull up a shell and go to your home directory, i.e. cd ~. You must not be in the ic210 or ic211 directory! Give the command:

git clone git@github.com:GoldPartnerGithubUsername/casino211.git

This should create a directory casino211. Please cd into it and ls. You should see a file README.md.

The Problem

Motivated by the talk last week on the "one-armed bandit problem", we are going produce a virtual casino with virtual slot machines. In particular, you are going to produce the program shown in the screenshot to the right and demo'd by your lab instructor. Obviously, this is a complicated thing to produce, especially since it's easy to imagine that we might later want to add more types of slot machines, more interesting visualizations of slot machines, better "reports", 2D layouts of slot machines, etc., and our design should make these kinds of new features as easy as possible to add. Moreover, there's a fair amount of work required, so you really want to plan your work in a way that allows you to make good use of all three lab partners.
Here are the basic rules governing how the slot machines work:

Playing a slot machine costs a quarter ($.25).
Each machine has a fixed payout $x for a win, which may differ from machine to machine
There are two basic machine types: Yoda and Pirate
- Yoda: playing a Yoda machine is like a coin flip, the machine has a win probability p (which differs from machine to machine). It shows a ⓗ on a win with the message "Strong is the Force in this one. Won you have.". On a loss it shows a ⓣ with the message "There is no win, only lose or lose not. Lost you did.".
- Pirate: playing a Pirate machine results in generating a random symbol from ♈✋⛵ three times in a row (show!). It's only a win if all three are the same. On a win it shows the message "You've won and taken me treasure, scaliwag!", on a loss "Arrrr, you lost, matey!".
Each slot machine has two pots of money: set aside for the casino, and available for payouts. The first quarter inserted by the player into a given machine goes to the set aside pot, the second to the available, and alternates back and forth from there. Money for a win may only be taken from the available pot. The machine is "out of service" if the amount in the available pot is less than the payout $x.
Note: the "report" for a machine shows the set aside (casino), available (pot), and set aside + available - initial available (net).

The format of file setup.txt is first a string Ms. The number of Ms is the number of machines. Then the machines listed one per line:

yoda 0.5 8.00 2.00    ← means a Yoda machine, p = 0.5, initial available = 8.00, payout $x = 2.00
pirate 10.000 1.50    ← means a Pirate machine, initial available = 10.00, payout $x = 1.50

Step 1: Design (produce a class dependency diagram)

You and your lab partners should go to a whiteboard and come up with a class dependency diagram, as described last class. Make sure you label edges with the methods that create dependencies, and "<extends<" for inheritance. This is your design!
Note: feel free to add more information or notes or ideas to the diagram!

Important! Do not move on to the next step until you've gone over your design with your professor. I mean it! If you start writing code we will fail you out of IC211 on the spot!

Step 2: Stub classes

A really important idea in object oriented programming is that you can create "stubs" - classes that have the public methods you intend to provide, but with dummy implementations that effectively to nothing. This allows dependent classes to be developed and even, to some extent, compiled, tested and debugged without waiting for the "real" version of the class to be written. For example, if your design has a class Machine that is supposed to provide a method double play() that simulates one play of the machine, printing out a message from the machine and returning the amount of money won, you might stub that out like this:

public class Machine {
  public double play() { System.out.println("Machine: --> 1.25"); return 1.25; }
  ⋮

Do not attempt to do useful work in your stub functions. Do the minimum amount required to return the type of object required by the method's signature, and print out some dummy message if the method is supposed to be printing out stuff. In particular, there should be no fields!

Your job: All partners sit at the Gold partner's computer and (quickly!) produce stubbed versions of all the classes in your design (only on that computer).

When complete:

First: Gold partner does

git add *.java
git commit -m "add stubs"
git push

Then: Other partners go to their computers and, in the casino211 directory, give the command: git pull
At this point all partners should have the same files!

Step 3: Work in parallel

Here's where the magic happens. Each team member, individually, pick a class and start working to implement the methods properly. You should write a main() for the class you've chosen that allows you to test the methods your implementing. Add fields as you need them and, with the fields, you might decide you need to add constructors as well. Once you've gotten your class as completed as you can, move on to another unclaimed class. There are two rules:

you can't have two different partners implementing the same class
if you want to change a method signature or add a constructor, get buyin from your partners, and make a note of it on your design

Bring it all together

When you've all gone as far as you can implementing your own classes based on the stub versions of the other classes, it's time to bring the implemented classes back together. Here's how:

Each partner: "git add" each .java file you implemented (not the ones the others worked on), then "git commit", then "git push". So, for example, if you implemented Machine.java and Yoda.java you would give the commands:
```
git add Machine.java Yoda.java
git commit -m "did my part"
git push
```
Gold partner only: git pull

Now the Gold partner should have all the implementations. Resume all partners working together at the Gold computer. Hopefully it doesn't take too much work to git the program compiled and running from there!