These are the slides of my Geecon09 speech about SOLID principles

1. SOLID Design Principles Bruno Bossola

3. Java developer since 1996

4. XP Coach during 2000-2001

5. Lead coordinator and co-founder of JUG Torino in 2001

6. Sun Java Champion since 2005

7. Speaker at Javapolis and Jazoon conferences

9. Bad design

10. Good design

11. SOLID principles

12. Conclusions

14. Note that those articles are dated...

15. 1992-1998!!! ...so please don't force me to get here next year!!!!

17. What's the difference if compared to analysis? Analysis is about what Design is about how

21. Are there any „symptoms” of bad design? Rigidity Fragility Immobility Viscosity

23. every change causes a cascade of changes in dependent modules

24. a nice „two days” work become a kind of endless marathon

25. costs become unpredictable

27. the breakage occurs in areas with no conceptual relationship

28. on every fix the software breaks in unexpected ways

30. the useful modules have too many dependencies

31. the cost of rewriting is less compared to the risk faced to separate those parts

33. preserving-design moves are difficult to think and to implement

34. it's much easier to do the wrong thing rather than the right one

41. OCP Open Closed Principle

42. LSP Liskov Substitution Principle

43. ISP Interface Segregation Principle

44. DIP Dependency Inversion Principle

48. Easier: a software module should have one reason only to change

49. It translates directly in high coesion

50. It's usually hard to see different responsabilities

54. group together things that change for the same reason

55. note the bias compared to "classical" OO

57. SRP requires very precise names, very focused classes

60. theorized in 1998 by Bertrand Meyer in a classical OO book

61. you should be able to extend the behavior of a module without changing it!

62. OCP?

63. OCP?

64. OCP!

66. Uncle Bob's recipe

67. keep the things that change frequently away from things that don't change

68. if they depend on each other, things that change frequently should depend upon things don't change

72. uh?

74. Function that use pointers or references to base classes must be able to use objects of derived classes without knowing it

76. Given an entity with a behavior and some possible sub-entities that could implement the original behavior, the caller should not be surprised by anything if one of the sub entities are substituted to the original entity

78. Should the square class extends rectangle?

80. It seems an obvious ISA

84. If I pass a Square to a Rectangle aware function, then this may fail as it may assume that width and heigth are managed separately

85. Geometry != Code

88. usually there are many clients each using a subset of the methods of such classes

91. instead they should rely on clean cohesive interfaces

92. you don't want to depend upon something you don't use

96. Abstractions should not depend upon details, details should depend upon abstractions

97. DIP?

98. DIP!

100. high level modules should not be forced to change because of a change in low level / technology layers

101. drives you towards low coupling

103. the main forces driving your design should be high cohesion and low coupling

104. SOLID principles put you on the right path

105. warning: these principles cannot be applied blindly :)