Design Exercise: Analyzing a Design

This exercise is intended for you to assess your design based on principles and how they help make your design more flexible to accommodate change. To help your assessment, make one more change to the design to see if your design is trending in the right direction (i.e., fewer significant or logic changes, more objects or methods added).

This exercise 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 design04_fluxx_analysis.md, to the individual portfolio_NETID repository provided for you in the course's Gitlab group.

Specification

Consider another variant on Fluxx called Pirate Fluxx.  In particular, the new card type: Surprise. 

Here are the differences in Pirate Fluxx from the original and Zombie Fluxx:

• Some Keeper Cards have an icon on them that marks them as a member of a category, either “Booty” or “Ship”
• Surprise Cards can be played either during your turn or during someone else’s turn and has two actions written on it: one if you play it on your turn and another if you play it on someone else’s turn

Here is the complete list of cards in Pirate Fluxx. The following examples highlight some new features to consider as you update your design:

• Flintlock Pistol Keeper: If you have this on the table, no one can Plunder from you unless they have the Captain’s Hat on the table
• Treasure Map Keeper: If you have this on the table, you may hide your Booty Keepers under it and it is like they don’t exist. Reveal them at any time, but you can only hide them again during your turn. This card cannot be Plundered, but if this card is lost or stolen, the Booty cards underneath go with it.
• Shackles Creeper: You cannot win if you have this card unless the Goal says otherwise. During your turn, you can discard this if you also discard a Booty Keeper from the table, or, you may give this card away if you have the Captain’s Hat on the table
• Scurvy Creeper: You can’t win if you have this. If you have Oranges or Limes on the table, discard this immediately. During your turn you can give this to another player if you had this during your previous turn.
• Shipwreck Action: All Ship Keepers in play are discarded
• Walk the Plank! Action: Choose a player. That player must discard their entire hand. If someone has the Captain’s Hat on the table, that player gets to choose who walks the plank.
• Long Live the Captain! Rule: Draw and play 1 extra card if the Captain’s Hat is anywhere on the table. Ignore any Keeper Limits if the Captain’s Hat is in front of you.
• Plunder! Rule: Once per turn you may steal any Keeper another player has on the table and put it in front of you. Plundering does not count as a Play.
• Land Ho! Goal: The player who has the Tropical Island and at least 1 Ship Keeper on the table wins
• Canceled Plans Surprise:
  • Out of turn: Discard a Goal another player has just played, thus stopping it from being used.
  • During your turn: Discard the current Goal(s). Also, all other players must discard a Goal or a random card from their hand.
• That Be Mine! Surprise:
  • Out of turn: When another player plays a Keeper, it goes in front of you instead of them, possibly preventing their victory.
  • During your turn: Steal another player’s Keeper and put it in front of you.

Add two new Use Cases to test your updated design based on the any of the cards above.

Update your design, the objects with their behaviors and relationships, and the Use Cases that test it to also support multiple versions of the game. Additionally, note the following as you make your changes:

• List all the changes needed in order to support the Pirate Fluxx version (new/different classes, methods, and parameters)
• Note any that involve changing existing code logic rather than making a new class or method

Analysis

Compare how many changes were needed this time to how many were needed for the last set of changes. Use that improvement (hopefully) as a basis for analyzing how effective your design is in the context of the general Design Principles introduced during class:

• Don’t Repeat Yourself (DRY): Factor out duplicated code, logic, and structures into constants, reusable methods or classes, and inheritance hierarchies. This makes your code easier to debug and removes a common source of errors.
• Tell, Don’t Ask: Classes should tell other classes to do a job (call a method), keeping each class's data private and giving all classes an active role in the program. This makes your code easier to reuse classes across programs and improve implementation details when needed.
• Loose Coupling: Classes depend on one another to the least extent possible and through clear abstractions. This makes your code easier to manage because changes in one class do not cause affect many other classes.
• Single Responsibility Principle: Every method or class should be in charge of one single logical thing. This makes your code easier to debug and easier to reuse.
• Open/Closed Principle: Classes should be open to extension and closed to modification. This makes your code's functionality easier to extend by providing new code, not changing existing code.

No design can follow every principle all the time. Rather, program design is balancing trade-offs. For example, you might add a “getter” to a class in order to enable the class to keep a single responsibility. It is important for you to not only be able to make a design decision, but also to defend the decision with principles like these, rather than general terms like "clearly/obviously", "good/sucks", "elegant/ugly", or "like/hate". Note, since no design is perfect, including both pros and cons of a design (i.e., its trade-offs) or alternate ideas you considered is highly encouraged.

For each of the design principles above, explain in which ways your design does and does not follow the principle and why you made the choices you did.