1. Mandatory 1 / AlphaCiv
… Traps to be aware of …

2. 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 )

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

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

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

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

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

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

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

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

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

13. Easter Eggs ?

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

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

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

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

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

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

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

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