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.

Correction: The handed out code's Hero interface is missing a method for the hero power's description. This is assumed by the user interface we will introduce later. So please update your Hero interface (and TDD the implementation) by adding a method:

  /** Get the text describing the hero's
   * power
   * @return short description of hero power/effect
   */
  String getEffectDescription();       
      

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/video 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.

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.