Is your code solid

3,040 views

Published on

Slides from my talk at DDD SW4

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,040
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
62
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Is your code solid

  1. 1. Principles behind good software design IS YOUR CODE SOLID?nathangloyn@NathanGloynDesign Code Releasenathan@gloyn.co.uk
  2. 2. Agenda The origin of S.O.L.I.D What is S.O.L.I.D? Design Smells The principles S.O.L.I.D code is... Summary Questions Resources
  3. 3. The origin of S.O.L.I.D Who is this man?
  4. 4. The origin of S.O.L.I.DPrinciples, Patterns, and Practices  Published in 2002  First book to mention SOLID  C# edition published 2005  Both books considered seminal works on SOLID
  5. 5. What is S.O.L.I.D? Principles about class design To be considered, not rules blindly applied Made up of acronyms Minimise design smells Easier to evolve code
  6. 6. Design Smells Rigidity Fragility Immobility Viscosity Needless Complexity Needless Repetition Opacity
  7. 7. The principles S ingle Responsibility Principle –> SRP O pen/Closed Principle –> OCP L iskov Substitution Principle –> LSP I nterface Segregation Principle –> ISP D ependency Inversion Principle –> DIP
  8. 8. The principles Single Responsibility Principle  What is the principle?  A class should have only one reason to change.  Why should you use it?  Helps with separation of concerns  Increases cohesion  Reduces coupling  Simplifies the code, making it more readable  Makes future changes easier
  9. 9. The principles Single Responsibility Principle Code
  10. 10. The principles Interface Segregation Principle  What is the principle?  Clients should not be forced to depend upon interfaces that they do not use  Avoid “fat” interfaces  Why should you use it?  Reduces coupling  Implementers only use bits they need.  Helps reduce dependencies
  11. 11. The principles Interface Segregation Principle Code
  12. 12. The principles Dependency Inversion Principle  What is the principle?  High-level modules should not depend on low- level modules. Both should depend on abstractions.  Abstractions should not depend upon details. Details should depend upon abstractions.  Don’t call us, we’ll call you
  13. 13. The principles Dependency Inversion Principle Policy Layer Mechanism Layer Utility Layer
  14. 14. The principles Dependency Inversion Principle Policy Service Policy Layer Interface Mechanism Service Mechanism Layer Interface Utility Layer
  15. 15. The principles Dependency Inversion Principle Policy Service Mechanism Service Policy Layer Interface Interface Mechanism Layer Utility Layer
  16. 16. The principles Dependency Inversion Principle  Why should you use it?  Reduces coupling  Makes it easier to reuse classes  Can make code easier to test  Use IoC to help implement
  17. 17. The principles Dependency Inversion Principle Code
  18. 18. The principles Open/closed Principle  What is the principle?  Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.  Add new code, don’t touch the old code  Why should you use it?  Systems easier to change/evolve  Reduces risk  Develop and test extensions in isolation
  19. 19. The principles Open/closed Principle Code
  20. 20. The principles Liskov Substitution Principle  What is the 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.  Subtypes must be substitutable for their base types.
  21. 21. The principles Liskov Substitution Principle  Why should you use it?  Consistent behaviour  Reduces coupling  Makes it easier to evolve code
  22. 22. The principles Liskov Substitution Principle Fail
  23. 23. The principles Liskov Substitution Principle Code
  24. 24. The principles S ingle Responsibility Principle –> SRP  A class should have only one reason to change. O pen/Closed Principle –> OCP  Add new code, don’t touch the old code L iskov Substitution Principle –> LSP  Subtypes must be substitutable for their base types I nterface Segregation Principle –> ISP  Avoid “fat” interfaces D ependency Inversion Principle –> DIP  Don’t call us, we’ll call you
  25. 25. S.O.L.I.D code is...  Loosely coupled  Highly cohesive  Easy to evolve/change  Testable
  26. 26. Summary Not new, been around a while Principles not rules You decide when to apply It should make it easier to evolve code Code will be easier to unit test
  27. 27. Questions?
  28. 28. Resources Principles Of Ood DimeCasts.Net – screen casts on each principle Los Techies – series of posts on principles Hanselminutes – podcast with Uncle Bob Getting a good SOLID start – post by Uncle bob Presentation Code – code from the presentation nathangloyn Design Code Release @NathanGloyn nathan@gloyn.co.uk

×