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.
The learning goals of this week are: (a) to analyze and refactor your current code base to clean up at least two methods so they adhere to Robert Martin's (and Henrik Bærbak's) properties of clean code; (b) to use the clean code template to ensure completeness of analysis as well as document it; and (c) to use the State pattern to implement ZetaStone.
Carefully read FRS § 37.4.1 which outlines the ZetaStone variant.
Spend the first 15-20 minutes of the class in plenum discussing...
Consider this HotStone endOfTurn()
implementation, and find examples of Clean Code principles
that are violated.
Time permitting, suggest ways to refactor the code to become more clean.
Choose two complex aspects (a complex method, or a feature coverede by a small set of methods) from your current HotStone implementation and for each first analyze it in terms of the Clean Code template, and next refactor it so it adheres as best as possible to the Clean Code properties. (endTurn(), attackHero() and attackCard() methods are likely candidates).
Refactor your code base on feature branch "iteration4", and document it as outlined in the report template (link below in 'Deliveries' section.)
Ensure that you have no items on your backlog before submitting this week. That is, all functional requirements on AlphaStone, BetaStone, GammaStone, and DeltaStone must now be fulfilled by your implementation!
Develop the ZetaStone variant using a compositional approach.
Deliveries:
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 4 Grade sheet to evaluate your submission.
Learning Goal | Assessment parameters |
Submission | Git repository contains merge request associated with branch iteration4. Git repository is not public! Required artefacts (report, screencasts, backlog) must all be present. The quality of screencast (video, audio) is OK. |
Clean Code Analysis | The analysis of the choosen methods are correct, and the clean code templates are correctly filled for each property. Argumentation is concise and correct. |
Refactoring | Refactoring is made to only clean up the properties mentioned. The screencast narration explains and refers to relevant clean code properties. All code changes are indeed refactoring changes (exact same behaviour before and after code changes). Test cases are run frequently to ensure small steps and no defects are introduced. |
State Pattern | The ZetaStone winning algorithm is designed and coded using a State pattern. Existing winning strategies from BetaStone and GammaStone are properly reused by composition (i.e. no source-code-copy reuse, polymorphic reuse, etc.). |