RPS Design Exercise

This exercise asks you to try to design a program without worrying about exactly how it will be implemented. In other words, without writing any actual implementation code, explore the trade-offs between several designs and describe the best one in enough detail that other programmers could implement it for you using any data structures or file format they want.

In groups of two or three, complete the following activities:

1. Create an initial design for the RPS problem
2. Use CRC cards to refine your design, focusing more on the interactions between classes than their implementation
3. Write code to solve some example Use Cases

Specification

Consider designing a software version of the eternal game of Rock, Paper, Scissors, RPS, that can support any number of choices (or this one) and their relationships as well as allow users to create new variations. Since there are RPS Championship Tournaments, it appears that there is a strategy (beyond simply cheating), if time permits you can consider how to represent "RPS intelligence" as well.

Write a high-level description of the classes you envision as part of implementing RPS, focusing on their behavior. High-level means explaining each class's purpose in the program (why it exists) without describing its implementation details. A class's behavior is its public methods, including any parameters and a return value. These method signatures should be written as they would appear in Java code, but your focus should be on describing their purpose in the class, not their implementation.

To record your group's design, fork the original project lab_rps into your own repository so you can edit, commit, and push your group's own changes. Use Gitlab's markdown format in your file. Here is a web-based WYSIWYG editor for markdown if you prefer.

You can assume a user interface will be provided for you that allows the user to choose a file containing the data about "weapons" available for a game and displays the results of each round of the game. Your program should accommodate reading from a data file and populating a data structure but, as much as possible, try to encapsulate both the file's format and the specific data structure so as few classes as possible need to know about it (if you even need to choose a specific one at all).

A picture may be helpful to show how your classes are related to and dependent on each other. The Use Cases below are provided to help you "test" your design against some specific scenarios.

Class-Responsibility-Collaborator Cards

Now that your group has thought about the problem generally, you will use CRC cards to refine your design and help you focus on interface instead of implementation issues. A CRC card is an index card (which nicely limits how much each class can do) that answers the following questions about a class to describe its behavior without getting into the details of how it implements that behavior. Index cards are also useful because they are easy to change and move around to see their relationship visually.

• What actions is this class responsible for?
• What other classes are required to help this class fulfill those responsibilities?
  These other classes will either be passed to this object's constructor or methods, or returned from a method, or created by this object internally.
  

Here are some examples of completed CRC cards. In these examples, the actions are given in English, not as a Java method signature (name, parameters, and return type). Your version must be written as a Java method signature to provide more details about the flow of the program.

When designing classes, one of the strengths of object-oriented design is creating objects model corresponding objects from the real world. However the best way to make an effective class is to "anthropomorphizing" it, i.e., to give it human characteristics and responsibilities — this is often what helps to distinguish a good object-oriented design (a group of intelligent objects collaborating together) from a bad one (a group of passive objects coordinated by a manager object).

Use Cases

The following scenarios are provided to help test the completeness and flexibility of your design. By writing the steps needed to complete each case below you will be able to see how effectively your design handles these scenarios and others will be able to better understand how deeply you have considered the basic issues.

• A new game is started with two players, their scores are reset to 0.
• A player chooses his RPS "weapon" with which he wants to play for this round.
• Given two players' choices, one player wins the round, and their scores are updated.
• A new choice is added to an existing game and its relationship to all the other choices is updated.
• A new game is added to the system, with its own relationships for its all its "weapons".

Here are some examples of completed Use Cases. In these examples, the steps are given in English, not as a Java method calls. Your version should be written as a sequence of calls to only those Java methods on your CRC cards to provide more details about the flow of the program.

It may help to role play or draw a diagram of how your classes collaborate to complete each case. For this exercise each step, try to include both the class used and the method used to accomplish the step. To make things more interesting, pair up with another team and try to do this part using their CRC cards.

Submission

At the end of class, use Gitlab's Merge Request to submit your group's design back to the original organization repository. Make sure the NetIDs of everyone in the group are in the title of your Merge Request and in the text file.