Mandatory 1 / AlphaCiv … Traps to be aware of …

Warn or not? I once asked Kent Beck the following –I have a lot of students in a course in design patterns. How can I best teach them the benefits? A) Give them a problem to solve, make them solve it, and then show a brilliantly simple solution using pattern X? B) Give them a problem and ask them to solve it using pattern X? Kent’s answer was:(To be given at lecture )

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

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 –Not a comprehensive quality assurance technique

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

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?

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

Misunderstood subclassing Class MountainTile implements Tile ? Why is the ratio liabilities/benefits so askewed that it is wrong to introduce MountainTile? Sorry, these are older slides. The getPosition() method was removed from the Tile interface in 2014.

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

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

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?

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?

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... ()

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

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

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

Easter Eggs ?

... And this What does this code do? War stories –Microsoft and easter eggs... –DSE and dead code springing to life...