Iteration 6: Compositional Design Principles

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

In this iteration, the learning goal is the compositional design principles, role interfaces and ISP, and composition's ability to support multi-dimensional variance, and contrast it to corresponding parametric and polymorphic designs. A secondary goal is refactor the creation of delegates into an Abstract Factory pattern.

Prerequisites

Carefully read FRS § 37.5 which outlines the ISP and private/role interface refactoring, and the new SemiStone and ThetaStone variant. ThetaStone is optional and of course it is also optional to include in your SemiStone.

Important: FRS Part 9 has been updated since the semester start, so ensure you download the latest release.

Kata

No Kata planned this week...

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.

  1. Describe your design of using private interfaces.
  2. Provide one or two examples of code, showing both the initial code and the refactored code.

FRS 2nd Edition §15.8 provides the theory you need, or, as an alternative, I have written this cheatsheet for private interface.

Abstract Factory

Refactor your present HotStone design to use Abstract Factory for creating delegates (like strategies for winner determination, mana production, deck building, hero powers etc). All your existing variants, Alpha, Beta, ..., should be represented by concrete factories.

SemiStone

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

  1. Produce a configuration table (see FRS Section 17.2 or the sketch in the report template below) outlining all variants and their variability points.
  2. Outline how SemiStone is configured in your code, and draw a UML class diagram of your design with emphasis on the SemiStone variant. (Avoid a "spaghetti diagram", see the hint below.)
  3. Implement the SemiStone variant.

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.

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.

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 request.
  2. You should document your group's work using the iteration 6 report template (pdf) (LaTeX source)

Notes

Drawing the full Abstract Factory UML diagram leads to way too many UML association lines---essentially making the diagram look like spaghetti. UML should provide clarity and overview, not a mess. So, do not draw the lines from factories to the individual concrete products (the strategies)---this is information that a developer (knowning the Abstract Factory pattern) will find in a configuration table or in the code instead.

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.

Learning Goal Assessment parameters
Submission Git repository contains merge request associated with "iteration6". Git repository is not public! Required artifacts (report following the template) are present.
Private Interfaces The report clearly and concisely describes the new design of card, hero, game using private interfaces. Casting to concrete classes/declaring datastructures by concrete classes have been removed. The code base and code examples correctly reflect introducing private interfaces.
Abstract Factory Pattern The abstract factory pattern is correctly designed and implemented, and well documented in the report.
SemiStone The report clearly and concisely describes the SemiStone configuration table and configuration code. The compositional design principles are correctly applied in the code base to support all variants and in particular support the multi-variance SemiStone. There are no source-code-copy, parametric, or polymorphic based variant handling code. The 'variant to use' code is localized in the ConcreteFactory for each variant.
Parametric Analysis The report clearly and concisely presents a correct solutions to the parametric 'getWinner()' through correct (pseudo) code fragments.
Polymorphic Analysis The report clearly and concisely describes a correct solution to the polymorphic ZetaStone through correct UML and (pseudo) code fragments.
TDD and Clean Code TDD process has been applied. Test code and Production code keeps obeying the criteria set forth in the previous iterations, including adhering to Clean Code properties for newly developed code. Missing features are noted in the backlog (ThetaStone features allowed there (permanently)).