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.
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.
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.
No Kata planned this week...
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.
FRS 2nd Edition §15.8 provides the theory you need, or, as an alternative, I have written this cheatsheet for private interface.
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.
Develop the SemiStone variant: The combination of all your most playable HotStone variants. Including ThetaStone, below, is of course optional.
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.
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.
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:
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.
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)). |