Your SlideShare is downloading. ×
Geecon09: SOLID Design Principles
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Geecon09: SOLID Design Principles


Published on

These are the slides of my Geecon09 speech about SOLID principles

These are the slides of my Geecon09 speech about SOLID principles

Published in: Technology

  • Worth reading
    Are you sure you want to  Yes  No
    Your message goes here
  • Great presentation! Thanks Bruno :-)
    Are you sure you want to  Yes  No
    Your message goes here
  • It was a great pleasure to watch that fantastic presentation. It's hard to make an enjoyable presentation on design principle... you know... design... architecture... oh it's so boring. But no! I haven't been bored at all! Thank you.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. SOLID Design Principles Bruno Bossola
  • 2. About me
    • C Developer since 1988
    • 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
  • 8. Agenda
    • What design exactly is about?
    • 9. Bad design
    • 10. Good design
    • 11. SOLID principles
    • 12. Conclusions
  • 13. Warning!
    • Most of those slides maps directly various articles available to the web, expecially from (thanks Bob!)
    • 14. Note that those articles are dated...
    • 15. 1992-1998!!! please don't force me to get here next year!!!!
  • 16. Design
    • What's the meaning of design?
    • 17. What's the difference if compared to analysis?
    Analysis is about what Design is about how
  • 18.
    • Why do we need (good) design?
    Design to manage change to deal with complexity to deliver faster
  • 19. Design
    • How do we know a design is bad?
    „ Hey, this is not the way I would have done this!” „ I can't understand this piece of code!” „ WTF?” „ WTF?” „ WTF?” „ WTF??” „ WTF??” „ WTF???”
  • 20. Design
    • Ok, we probably need better criterias :)
    • 21. Are there any „symptoms” of bad design?
    Rigidity Fragility Immobility Viscosity
  • 22. Rigidity
    • the impact of a change is unpredictable
    • 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
  • 26. Fragility
    • the software tends to break in many places on every change
    • 27. the breakage occurs in areas with no conceptual relationship
    • 28. on every fix the software breaks in unexpected ways
  • 29. Immobility
    • it's almost impossible to reuse interesting parts of the software
    • 30. the useful modules have too many dependencies
    • 31. the cost of rewriting is less compared to the risk faced to separate those parts
  • 32. Viscosity
    • a hack is cheaper to implement than the solution within the design
    • 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
  • 35. Design
    • What's the reason why a design becomes rigid, fragile, immobile, and viscous?
    improper dependencies between modules
  • 36. Good design
    • So, what are the characteristics of a good design?
    high coesion low coupling
  • 37. Good design
    • How can we achieve a good design?
    Let's go SOLID !!! S RP O CP L SP I SP D IP
  • 38.  
  • 39. SOLID
    • An acronym of acronyms!
    • 40. It recalls in a single word all the most important pricinple of design
      • SRP Single Responsabiity Principle
      • 41. OCP Open Closed Principle
      • 42. LSP Liskov Substitution Principle
      • 43. ISP Interface Segregation Principle
      • 44. DIP Dependency Inversion Principle
  • 45. BREAK!
    • What is the best comment in source code you have ever encountered? (part 1)
  • 46.  
  • 47. Single Responsability Principle
    • A software module should have one and only one responsability
    • 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
  • 51. SRP
    • Is SRP violated here?
  • 52. SRP
    • Is SRP violated here?
  • 53. SRP
    • identify things that are changing for different reasons
    • 54. group together things that change for the same reason
    • 55. note the bias compared to "classical" OO
    • 56. smells? *Manager, *Controller, *Handler
      • you really don't know how to name those
      • 57. SRP requires very precise names, very focused classes
  • 58.  
  • 59. Open Closed Principle
    • Modules should be open for extension but closed to modification
    • 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!
  • 65. OCP
    • Abstraction is the key!
    • 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
  • 69. BREAK!
    • What is the best comment in source code you have ever encountered? (part 2)
  • 70.  
  • 71. Liskov Substitution Principle
    • If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.
    • 72. uh?
  • 73. LSP
    • Try #2:
    • 74. Function that use pointers or references to base classes must be able to use objects of derived classes without knowing it
  • 75. LSP
    • Try #3:
    • 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
  • 77. LSP (by example)
    • How would you model the relationship between a square and a rectangle?
    • 78. Should the square class extends rectangle?
  • 79. LSP (by example)
    • Of course, isn't the Square a kind of Rectangle, after all?
    • 80. It seems an obvious ISA
  • 81. LSP (by example)
    • But... what about:
      • rectangle has two attributes, width and height: how can we deal with that?
      • 82. how do we deal with setWidth() and setHeight() ?
    • Is it safe?
  • 83. LSP (by example)
    • No, behavior is different
    • 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
  • 86.  
  • 87. Interface Segregation Principle
    • fat classes may happen :(
    • 88. usually there are many clients each using a subset of the methods of such classes
    • 89. such client classes depend upon things they don't use
      • what happens when the big class changes? all depending modules must also change
  • 90. ISP
    • ISP states that clients should not know about fat classes
    • 91. instead they should rely on clean cohesive interfaces
    • 92. you don't want to depend upon something you don't use
  • 93. BREAK!
    • What is the best comment in source code you have ever encountered? (part 3)
  • 94.  
  • 95. Dependency Inversion Principle
    • High level modules should not depend upon low level modules, both should depend upon abstractions
    • 96. Abstractions should not depend upon details, details should depend upon abstractions
  • 97. DIP?
  • 98. DIP!
  • 99. DIP
    • don't depend on anything concrete, depend only upon abstraction
    • 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
  • 102. Conclusion
    • good design is needed to successfully deal with change
    • 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 :)
  • 106. Q&A [email_address] Credits and links
    • All about design principles:
    • SOLID in motivational pictures: (
    • My original OO coach, Francesco Cirillo