Design Exercise: Fluxx Objects

This exercise is intended for you to try to start designing a program without worrying about how it will be implemented. Thus, without implementing any functionality, determine a set of objects that you think represent elements in the problem and can work together to implement a solution. It will not be explicitly graded but, instead, serve as practice for future exercises in the course. Thus, you will get the most out of this assignment by putting in a good faith effort.

Submission

Submit a Markdown formatted plain text file, named design01_fluxx_objects.md, to the individual portfolio_NETID repository provided for you in the course's Gitlab group. All submissions for this course will be based on only the version of your files in the provided Gitlab repository by 3:07am ET in the morning on the day after that given on the course Calendar (so it is effectively a few extra hours grace time past midnight).

A template to get you started is also included in your portfolio_NETID repository.

Describe a set of classes you see collaborating to model the game of Fluxx. For each class in your design, include the following:

• purpose: what the class models in the game (i.e., why it exists)
• behaviors/responsibilities: its public methods, including any parameters and a return value
• collaborators: any other classes it needs to interact with that are not given as parameters or returned from methods (i.e., separate instance variables)

Your focus should be on describing a class's behavior, not its implementation details or a specific data structures.

We suggest using CRC cards to capture your design. To show your CRC cards in your Markdown document, you can either use actual index cards (or small pieces of paper) and include pictures of them or you can create tables to represent an index card digitally.

Specification

Individually, describe a design for the card game of Fluxx by Looney Labs, which has dynamically changing rules so that each game is a unique experience like the family of games with mutable rules. The game starts out with just two basic rules: each player draws one card and then plays one card during her turn — there is not even a way to win the game! After that, almost any part of the play can be changed by playing Rule or Goal cards (the rules and goals are on the cards, so as you play, anything can change). Most people are divided between those that love the challenge and variety presented by the game and those that hate the lack of strategy possible (I have even known people to play cards that allow others to win just to end the game!).

There are four main types of cards:

• Keepers: game items
• Actions: things to do once, when the card is played
• New Rule: restrictions on game play that can change over the course of one game
• Goal: objectives that can end the game

To familiarize yourself with the game, try playing a version online here, download an app (iOS or Android), or watch some videos on YouTube.

Object Oriented Design

One of the strengths of object-oriented design is creating program objects that model corresponding objects from the real world when designing classes. The best way to design an effective class is to "anthropomorphize" the real world object, i.e., give it human characteristics and responsibilities, because it gives the class agency through active behaviors and thus a more defined role in the design. This distinguishes a good object-oriented design (a group of collaborating objects) from a bad one (a group of passive objects coordinated by a "manager" object).

Thus, when creating a design, focus first on each class's behavior (the methods a class implements) rather than its state (instance variables). Then for each behavior that fits with a class, give it a clear purpose by thinking about how much easier it would make the project if such a method already existed (even if you are not currently sure how to implement it). But balance that with making the behavior as general as possible to give a coder room to change their mind about the implementation when they have to write it.

After thinking about a problem generally, many people find CRC cards useful to describe a Object-Oriented design because they help make the objects more concrete, the logical relationship between objects explicit, it is easier to understand, evaluate, and modify a design. A CRC card is an index card (which nicely limits how much a class can do and are easy to change and move around to see their relationship visually) that helps you focus on making active objects by answering the following questions for each class:

• What active behaviors is this class responsible for (rather than get/set methods)?
  These are the public methods other objects can call on this one without knowing how it implements that behavior.
• 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, returned from a method, or created by this object itself.
  

Here is an example of developing complete CRC cards. However, these examples show the responsibilities in simple English, not as a Java method signature (name, parameters, and return type). Your version must be written as a Java method signature to help provide more details about the flow of the program.

Resources

• All cards in the basic Fluxx game
• Rule sheet for the basic Fluxx game
• Clarifications on rule "ambiguities"