Successfully reported this slideshow.
Your SlideShare is downloading. ×

Single Responsibility Principle @ Clean Code Alliance Meetup

Advertisement

More Related Content

Advertisement

Single Responsibility Principle @ Clean Code Alliance Meetup

  1. 1. Single Responsibility Principle By Eyal Golan
  2. 2. About Me 2 Senior Java developer and agile practitioner. Practicing TDD, clean code. Software craftsmanship advocate. Tech lead / Scrum master @ eBay Team lead @ StartApp, doing, among other things: ● Manages the continuous integration and deployment of the system. ● Leading the coding practices. Engineering team lead @ AppLift (Berlin)
  3. 3. Agenda 1. SOLID 2. SRP overview 3. Why SRP? 4. Recognizing SRP violation 5. Develop for SRP 6. Summarize 3
  4. 4. 4
  5. 5. • Robert C. Martin – Uncle Bob • http://en.wikipedia.org/wiki/SOLID_(object- oriented_design) 5 Single responsibility principle Open / closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle
  6. 6. SOLID • Single responsibility principle • A class should have only a single responsibility 6
  7. 7. SOLID • Open/closed principle • Open for extension, but closed for modification • Alistair Cockburn: “…Identify points of predicted variation and create a stable interface around them…” 7
  8. 8. SOLID • Liskov substitution principle • Replace objects with instances of their subtypes without altering the correctness of that program 8 Rectangle Square
  9. 9. SOLID • Interface segregation principle • Many client-specific interfaces are better than one general-purpose interface 9
  10. 10. SOLID • Dependency inversion principle • Abstractions should not depend on details • Don’t depend on anything concrete • Work with interfaces 10
  11. 11. 11 Single Responsibility Principle
  12. 12. Single Responsibility Principle • Wikipedia • …the single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility… • Clean Code • A class or module should have one, and only one, reason to change 12
  13. 13. Which Components? • Methods • Classes • Packages • Modules • System 13
  14. 14. 14 Why SRP ?
  15. 15. Why SRP? • Organize the code 15 George A. Miller
  16. 16. Why SRP? • A place for everything and everything in its place 16
  17. 17. Why SRP? • Less fragile code • Low coupling • High cohesion 17
  18. 18. Why SRP? • Easier code changes (Refactoring) 18
  19. 19. Why SRP? • Easier naming • The smaller and more focused class, it will be easier to name 19
  20. 20. Why SRP? • Maintainability • Testability and easier debugging 20
  21. 21. 21 Recognizing SRP Violation
  22. 22. Recognizing By Structure • Class / method is too long 22 Class: LOC > 250 Bad
  23. 23. Recognizing By Structure • Too many dependencies (fields / parameters) 23 Class Dependency 1 Dependency 2 Dependency 3 Dependency 4 Dependency 5 Dependency 6
  24. 24. Recognizing By Structure • Low cohesion 24
  25. 25. Recognizing By Structure • Description / name needs: “AND” • Generic name: “EmployeeManager” 25 void calculateAndSend(…)
  26. 26. Recognizing By Structure • A method with many levels 26 if while
  27. 27. Recognizing By Behavior • Class needs to be changed for more than one behavioral change 27
  28. 28. Recognizing By Behavior • Complicated test 28 when(…).then(…); when(…).then(…); when(…).then(…); when(…).then(…); when(…).then(…); when(…).then(…);
  29. 29. Recognizing By Behavior • Change here, break there • Test may be broken elsewhere • The “shotgun effect” 29
  30. 30. Recognizing By Behavior • Unable to encapsulate the module 30
  31. 31. 31 Develop For SRP
  32. 32. Develop for SRP • Awareness • The state or ability to perceive, to feel, or to be conscious of events, objects, or sensory patterns 32
  33. 33. Develop for SRP • Testable code • TDD 33 Test CodeRefactor
  34. 34. Develop for SRP • Code quality metrics • Coverage • SONAR 34
  35. 35. Develop for SRP • Use other principles • High cohesion • Decrease coupling • Interfaces • Real encapsulation • Law of Demeter 35
  36. 36. Develop for SRP 36 Keep it simple, stupid! Keep it simple and short! Keep it simple, short and specific!
  37. 37. Develop for SRP • Naming • Think about it • Role play your entities • Longer and more focused name 37
  38. 38. Develop for SRP • Extract method • Extract class 38
  39. 39. Develop for SRP • Refactor mercilessly • Use design patterns • Keep modularization clear 39
  40. 40. Example 40 Precise name (method, class) Short class, 35 lines High cohesion
  41. 41. Conclusion • OOD • Clean code • Better practice 41 Do 1 thing A class should have one reason to change! SRP
  42. 42. Resources • http://butunclebob.com/ArticleS.UncleBob.Principles OfOod • Uncle Bob about SRP • http://www.codinghorror.com/blog/2007/03/curlys- law-do-one-thing.html • Coding Horror • https://docs.google.com/file/d/0ByOwmqah_nuGNH EtcU5OekdDMkk/ • PDF about SRP • http://eyalgo.com/2014/02/01/the-single- responsibility-principle/ • My blog post about SRP 42
  43. 43. Simple, Isn’t It? 43
  44. 44. Q & A 44
  45. 45. 45 Thank You ! Eyal Golan egolan74@gmail.com Connect @eyalgo_egolan http://eyalgo.com/

×