Iteration 6: Compositional Design and Test Spy

Deadline

At 23.59 on the day that your class has agreed with the TA.

Any late hand-in must be agreed with your TA; failing to do so will allow the TA to reject evaluating your hand-in.

Workload Estimate

High

Learning Goals

The learning goals are Private Interfaces, Test Spy and again the compositional design principles.

Prerequisites

Carefully read FRS § 37.5 which outlines the Interface-Segregation-Principle and private/role interface refactoring, and the new EtaStone and SemiStone (and optionally ThetaStone) variants. FRS 2nd Edition §15.8 and §15.9 provides the theory you need.

Exercises

Private Interfaces and ISP

Refactor your HotStone code base to adhere to the Program to an Interface principle by introducing appropriately named private interfaces to handle mutation of internal game state.

Document your design as outlined in the report template.

FRS 2nd Edition §15.8 provides the theory you need, and, as a supplement, I have written this cheatsheet for private interface.

EtaStone

Note that this exercise strongly requires you to have developed a private interface for Game, as outlined in the previous exercise, to be solved correctly!

Develop EtaStone using TDD by refactoring the existing HotStone production code, and using a Test Spy to ensure card effects are Unit Tested, and not Integration Tested.

Document your card effect testing and argue for unit testing as outlined in the report template.

SemiStone

Develop the SemiStone variant: The combination of all your most playable HotStone variants. Including ThetaStone, below, is of course optional.

Document your design as outlined in the report template.

Parametric 'getWinner()'

Consider the situation that you have designed all variants using a purely parametric design . That is, all variable behaviors are controlled by if's and switches in a single large implementation of Game containing code for all the requirements.

Sketch how method 'getWinner()' would look like this if a purely parametric design had been employed as variant handling technique in the HotStone code.

Optional: Polymorphic ZetaStone

Consider the situation that you have designed all variants using a purely polymorphic design. That is, a design in which variants are created by subclassing the original AlphaStone implementation, like shown below:

For instance, the BetaStone winning algorithm would be handled by overriding the getWinner() method in class AlphaStone, etc.

1. Sketch a design proposal for how to implement ZetaStone based upon a purely polymorphic design, by drawing a UML diagram of the interfaces and classes involved. You may only consider a design in a language that does not support multiple implementation inheritance, like Java.
2. Sketch how the actual getWinner() method implementation in the ZetaStone subclass would look like in (pseudo) code.

Optional: ThetaStone

Develop ThetaStone using TDD and by generalizing/extending your HotStone production code. Be sure to use a role interface for Categories.

This is purely an optional exercise, for 'fun' and improved game play.

Deliveries:

1. Develop on a feature branch named "iteration6" and release using a merge.
2. You should document your group's work using the iteration 6 report template (pdf) (LaTeX source)

Evaluation criteria

Your submission is evaluated against the learning goals and adherence to the submission guidelines. The grading is explained in Grading Guidelines. The TAs will use the Iteration 6 Grade sheet to evaluate your submission.