1. Mandatory 1 / AlphaCiv … a few comments…

2. Overall: Generally – good work – good effort Seems you are generally doing TDD Minor hick-ups –”My own way is far superior, no need to learn TDD” –”I am too slow a programmer, better let super-joe do all the coding”

3. Doing TDD Evident Tests Exercise: What is focus here? –Test that everything works? Or –Drive production code into existence?

4. What is TDD??? Traditional tests = Quality Assurance Technique –Success: test cases that show absence of defects TDD tests = Implementation Technique –Success: test cases that drive implementation –Perhaps a few more to show absense of defects

5. An example Iteration 1: Fake it using anonymous tile class Iteration 2: Intro datastructure, intro StandardTile, fill all with plains Productioncode driver Reliability

6. Evident tests again Why do you not think all CityImpl are the same? –Just test the production code on one instance! Exercise:Is it OK to use CityImpl here –Answer: Yes indeed. Why?

7. Production and Test Code Separate test and production code as best possible! Morale: No test code in the production code Seen in GameImpl:

8. Misunderstood subclassing Class MountainTile implements Tile ? Why is the ratio liabilities/benefits so askewed that it is almost at the point that it is wrong?

9. When to use subclassing! Only use subclasses if you get a distinct behavioural advantage –Otherwise it is a lot of typing just to define some constant –Similar for units: cost, defense, attack,.... Parameterization is run- time changeable, cheap, easy to overview...

10. Regarding Units Unit types are behavioural distinct! So: SettlerUnit extends AbstractUnit Impl. Unit ? Polymorphic design and it will work –With some not-so-nice hacks ala How does a settler unit kill itself as part of its action? But the learning goal in dSoftArk is compositional design –Make a UnitImpl, and delegate actions to a Strategy! –See if you can get through... Tricky with Archers though

11. Keeping the facade Since I wrote the book I have become more strict in my understanding of mutation... Exercise: a)How is a city created? b)What happens when it does? b) How is production set? And how many ways can we set it? And how to ensure consistency?

12. Design Issues Read-only interfaces for City, Tile, Unit – Why? –Otherwise two ways of changing state in a game Through Game which will enforce consistency Through City which will NOT enforce consistency –If there are two ways Bjarne will use the wrong one! Morale: Only Game has mutator methods! But how to change state? –Only CityImpl has mutators; GameImpl only use CityImpl? –ModifiableCity interface; GameImpl only use that –GameImpl takes on all responsibility?

13. Sketches Knowing the Implementation type in Game Liabilities –Fails if we must allow external clients to configure our Game with new City implementations  Dependency injection and stuff... ()

14. Sketches Using an ”modifiable interface” Now the Game can get any class that implements ModifiableCity injected and handle it... ModifiableCity

15. My opinion It is fully OK for GameImpl to –Operate through CityImpl, UnitImpl, etc. –Do a cast ala (CityImpl) this.getCityAt(p) –Why: Because we are developing the internal production code The GUI guys only use Game interface The Domain guys (= us) use the internals

16. My opinion ”More beautiful” to use a ‘ModifiableCity’ interface? Simplicity: maximize work not done –We do not need it at the moment –It introduces more complexity –If need arise, easy to refactor CityImpl -> ModifiableCity

17. Easter Eggs ?

18. From last year... What does this code do? War stories –Microsoft and easter eggs... –DSE and dead code springing to life...