Slides used at the TDD Milano event of Tuesday September, 5th 2017 (https://www.meetup.com/it-IT/TDD-Milano/events/242001466/).

1. Agile Design Episode 2
Applied Open-Closed
Principle
Andrea Francia
TDD Milano - Tuesday September, 5th 2017

2. TDD Milano news

3. Round table delle
communities italiane
all’Agile Day?

4. Gruppo TDD Milano su
Google Groups
• https://groups.google.com/forum/#!forum/tdd-milano

5. Le prossime conferenze
Agile Business Day
Venerdì 16 Settembre 2017 a Venezia
http://www.agilebusinessday.com/
Codemotion Milano
8 e 9 novembre 2017 a Milano
http://milan2017.codemotionworld.com/
Italian Agile Day
venerdì 17 e sabato 18 novembre 2017 a Urbino
http://www.agileday.it/
NoSlidesConf
sabato 25 novembre 2017, a Bologna
http://www.noslidesconf.net/

6. Learning objectives
• How do we do design during Test Driven Development?
• When to do refactor in TDD?
• How much refactor should we do?

7. Why design is
important?

8. Kent Beck. 1999. Extreme Programming Explained: Embrace Change
Legacy Code
Clean Code

9. When Refactor?

10. http://agileinaflash.blogspot.it/2009/02/red-green-refactor.html

11. Refactor last?
• RED
• GREEN
• REFACTOR

12. Refactor first?
• REFACTOR
• RED
• GREEN

13. Refactor first and last
• REFACTOR (to make easier add the new feature)
• RED
• GREEN
• REFACTOR (to remove any duplication)

14. How long to stay in
each phase?

15. http://agileinaflash.blogspot.it/2009/02/red-green-refactor.html

16. The TDD Rhythm:
1. Quickly add a test
2. Run all tests and see the new one fail
3. Make a little change
4. Run all tests and see them all succeed
5. Refactor to remove duplication

17. The TDD Rhythm:
1. Quickly add a test
2. Run all tests and see the new one fail
3. Make a little change
4. Run all tests and see them all succeed
5. Refactor to remove duplication

18. http://agileinaflash.blogspot.it/2009/02/red-green-refactor.html
1-2 minutes
1-2 minutes
take your time

19. The Open/Closed
Principle

20. The “O” in SOLID
• Single Responsibility Principle (SRP)
• Open/Closed Principle (OCP)
• Liskov substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

21. The Open/Closed Principle
Betrand Meyer’s definition:
“Modules should be both open and closed.”

22. The Open/Closed Principle
Robert Martin’s definition
“Software entities (classes, modules, functions, etc.)
should be open for extension but closed for
modification.”

23. Open and Closed
• Open for extension means we can extend the module
with new behaviors that implements new requirements
(we can change what the module does).
• Closed for modification means that extending the
behavior of a module does not result in changes to the
source, or binary, code of the module.

24. Open/Closed Principle
found in the wild
public static void main(String[] args) {
List<Integer> list = asList(3, 2, 1);
// standard sort
Collections.sort(list);
printAll(list);
// sorting with a specific comparator
Collections.sort(list, pronounceComparator());
printAll(list);
}
private static Comparator<Integer> pronounceComparator() {
return (o1, o2) -> {
String s1 = pronounce(o1);
String s2 = pronounce(o2);
return s1.compareTo(s2);
};
}

25. How to learn to apply
OCP?

26. Kata (repetition)

27. OCP Kata
Open-Closed Principle Kata: http://matteo.vaccari.name/blog/archives/293

28. When do we refactor?
Starting code base Changes implemented
red == code changed
(Hopefully) Code cleaned up
Refactor
after
Starting code base Change design to make
room for new feature
Implement feature
Refactor
before
From a slide by Dave Nicolette

29. OCP Kata Rules
1. Write the first failing test

30. OCP Kata Rules
1. Write the first failing test
2. Then write a factory that returns an object, or an
aggregate of objects, that make the test pass.

31. OCP Kata Rules
1. Write the first failing test
2. Then write a factory that returns an object, or an
aggregate of objects, that make the test pass.
3. Write the next failing test.

32. OCP Kata Rules
1. Write the first failing test
2. Then write a factory that returns an object, or an
aggregate of objects, that make the test pass.
3. Write the next failing test.
4. Make the test pass adding, changing (or deleting) just
one object in the factory

33. OCP Kata Rules
1. Write the first failing test
2. Then write a factory that returns an object, or an
aggregate of objects, that make the test pass.
3. Write the next failing test.
4. Make the test pass adding, changing (or deleting) just
one object in the factory
You can’t? Then refactor your code until you can!

34. Workshop time
• git clone https://github.com/andreafrancia/ocp-kata.git
• cd ocp-kata
• start-up your IntelliJ IDEA