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

How I will do it… Iteration 1: Fake it using anonymous tile class Iteration 2: Intro datastructure, intro StandardTile, fill all with plains Productioncode driver Reliability

And then I… Add test cases for each of the ‘exceptions’ Test drive that one tile that is a mountain Write the test case ‘shouldHaveMountainAt2_2()’ See it fail Enhance the production code to world[2][2] = new StandardTile(GameConstants.MOUNTAIN); (or world.put(new Position(2,2), new StandardTile…..) (or …) See it pass Test drive that one that is Ocean You get it…

… and one more hint Have a look at my screencast on weekplan 2 ‘unit-move-faked’

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 (as in ‘use City interface instead’) Answer: Yes indeed. Why? Because we are TDD’ing the implementation of City, and the getTreasury() may just be a method on the IMPL class. Do unit testing of City, Unit, etc; and less testing through the Game. Unit Testing

Production and Test Code Separate test and production code as best possible! Morale: No test code in the production code Unless you cannot avoid it… Testability is more important than encapsulation… As long as you do not make mutators… Seen in GameImpl: One of the big issues in dSoftArk – it is about design and no absolute truths nor QEDs.

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... One issue: Too many academic textbooks overuse subclassing. They are plainly wrong!

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! In the next mandatory exercises, for now just ‘simplicity’ See if you can get through... Tricky with Archers though 

Easter Eggs ?

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

Read-Only Interfaces Warning: The next couple of slides are a bit complex… The central statements are: Only the Game instance is allowed to modify internal game state… How do we ensure that there are no other mutator methods visible to, say, the GUI programmers than those in Game interface? Return to these slides when need arise…

Keeping the facade Since I wrote the book I have become more strict in my understanding of mutation... Exercise: How is a city created? What happens when it does? b) How is production set? And how many ways can we set it? And how to ensure consistency? If ‘game’ is declared as ‘Game’ this is wrong, as we open up for creating-cities-through-other-means-than-the-game-rules-that-require-a-settler. If ‘game’ is a GameImpl, then createCity can be a package protected method, and I would say it is OK; it is shielded from being misused by Bjarne in the GUI department. However City is problematic, as it now has a ‘setProductionCurrency’ method that may mutate its state outside of Game’s control

Morale: Only Game has mutator methods! 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