Iteration 3: Strategy Pattern and Refactoring

Deadline

Always at 23.59 on the same day as your TA session (Except if another deadline has been agreed with the TA). Consult the deadline for your class on the delivery plan.

Learning Goals

The learning focus in this iteration is twofold: A) refactoring your HotStone code base to an Strategy pattern based architecture, by using your existing test cases to refactor the code base to a new design; and B) introduce new variants of the HotStone game by implementing new Strategy implementations.

Prerequisites

Carefully read FRS § 37.3 which outline the new BetaStone, GammaStone, and DeltaStone variants.

Kata

Spend the first 15-20 minutes of the class in plenum discussing...

AlphaStone and BetaStone vary with respect to determining who wins the game: In Alpha, Findus always wins after eight turns, while in Beta, the winner is the one whose opponent hero's health reaches zero or less. As a Strategy pattern dictates that the winner algorithm is in another object distinct from the Game object there obviously must be passed information back and forth between the Game and the Strategy.

Discuss benefits and liabilities of choosing each of these viable ways of passing parameters from Game to the Strategy algorithm:

  1. passing: turnCount, findus health, peddersen health (all integers)
  2. passing: game object (type: interface Game)
  3. passing: game object (type: class StandardGame/GameImpl)
  4. passing: a Record type containing a copy of all game state (turn count, player in turn, heroes' data (mana, health, power used), fields' contents (all cards and their values), etc.)

One of these options will be the lesser choice if case we invent future strategies for determining the winner based on other criterias. Which one?

Exercises

BetaStone

Develop the BetaStone variant using TDD by refactoring the AlphaStone production code. Both variants must be maintained.

Sketch a compositional design for the HotStone system that supports the variants, and then refactor the AlphaStone production code to implement your design. Ensure your AlphaStone passes all test cases before starting to implement BetaStone. I advise to put common code into suitable packages, like hotstone.framework and hotstone.standard, but variant code in some other package, ala hotstone.variants or similar; and make similar changes in the test tree.

GammaStone

Develop the GammaStone variant using TDD by refactoring the HotStone common production code. All variants must be maintained.

Sketch a compositional design for HotStone to support the new variant, and refactor the existing HotStone production code to support the new design while all existing variants pass their test suites. Next, implement the GammaStone variant using TDD.

Note 1: Regarding the GammaStone solution use a Strategy pattern based approach for the GammaStone design! A sub-classing approach is not wrong, it is just that we want to train skills in applying a compositional design in this course. More details can be found in the W4-4 Mandatory Hints slides for the week.

Note 2: GammaStone strategies need to affect the state of the game, it is not a "pure function" as was the case with Beta. More details on ways to do that in the W4-4 Mandatory Hints slides.

DeltaStone

Develop the DeltaStone variant using TDD by refactoring the HotStone common production code. All variants must be maintained.

Sketch a compositional design for HotStone to support the new variant, and refactor the existing HotStone production code to support the new design while all existing variants pass their test suites. Next, implement the DeltaStone variant using TDD.

Deliveries:

Develop on a feature branch named "iteration3" and release using a merge request.

  1. Create one 5-8 minute screencast that demonstrates the refactoring process in which you introduce the compositional design for one of the strategies that will allow introducing one of the Beta-, Gamma-, or DeltaStone behavior. (I.e. the resulting code should still only support AlphaStone behavior but have the proper architecture in place for introducing the selected X-Stone requirement. Only one strategy should be included.)
  2. Create one 4-5 minute screencast that details the 3-1-2 process/compositional design, the architecture and implementation of one of the required variants, specifically, you should screencast/show the code and explain its relation to 3-1-2 and Strategy pattern (no coding involved). Be sure to show and explain a) the interface(s) introduced, b) the variability point(s), c) the place(s) where variable behavior is selected ("this code chooses whether it becomes an AlphaStone or GammaStone game"), and d) the implementing delegates.
  3. An UML class diagram outlining the final compositional design including all variants. Only include aspects relevant for the compositional design/Strategy patterns, and avoid others such as Position, storage data structures, etc. Please, in your interfaces, include the method(s) that encapsulate the central algorithm! (Provide it as a diagram in PDF, or picture of a easily readable hand-drawn diagram).

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 3 Grade sheet to evaluate your submission.

Learning Goal Assessment parameters
Submission Git repository contains merge request associated with "iteration3". Git repository is not public! Required artifacts (document with contents as outlined in the sections) must all be present.
Refactoring Process The code base is refactored before introducing test cases/production code for the given variant. All code changes are indeed refactoring changes (exact same behavior before and after code changes). Test cases are run frequently to ensure small steps and no defects are introduced.
Composition The Strategy pattern and 3-1-2 process have been correctly applied in the code base to support the variants. There is no source-code-copy, parametric, or polymorphic based variant handling code. The 3-1-2 and Strategy pattern terminology is used correctly in the screencast to explain the design and process.
Unit and Integration Testing The delegates/concrete strategies are unit tested/tested in isolation (if possible). Integration tests exist that test each of AlphaStone, BetaStone, GammaStone, and DeltaStone as a whole. Test classes are named appropriately. See footnote below.
UML The UML diagram is syntactically correct, correctly reflects Strategy, and is a correct overview of the architecture (including aggregation arrows from interfaces to delegates, which is proper for this course). The UML diagram does not show irrelevant implementation oriented details. The interfaces include the method(s) that encapsulate the central algoritm.
TDD and Code TDD process has been applied. Test code and Production code keeps obeying the criteria set forth in the previous iterations. The requirements of BetaStone, GammaStone, and DeltaStone are correctly implemented (minor deviations allowed). Missing features are noted in the backlog.

Unit and Integration Testing clarification: Some concrete strategies can be tested in isolation, that is, unit tested without the StandardGame/GameImpl instance. If possible, please do so. Regarding naming of test classes, do not put tests of BetaStone into a test class named "TestAlphaStone" etc. Separate test suites into test classes with descriptive names, like done in FRS chapter 8.1.5 and onwards.