Single Responsibility Principle @ Clean Code Alliance Meetup
Download as PPTX, PDF•4 likes•7,713 views
This document discusses the single responsibility principle (SRP) of object-oriented design. SRP states that every class should have a single responsibility, and its services should be narrowly aligned with that responsibility. Following SRP leads to code that is more organized, less fragile, easier to name and change. Violations of SRP can be recognized through structures that are too long or complex, or behaviors where a class needs to change for multiple reasons. Developers should follow SRP by writing testable code, using metrics to measure quality, applying other design principles, and refactoring code mercilessly.
Single Responsibility Principle @ Clean Code Alliance Meetup
- 1. Single Responsibility Principle By Eyal Golan
- 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. Agenda 1. SOLID 2. SRP overview 3. Why SRP? 4. Recognizing SRP violation 5. Develop for SRP 6. Summarize 3
- 4. 4
- 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. SOLID • Single responsibility principle • A class should have only a single responsibility 6
- 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. SOLID • Liskov substitution principle • Replace objects with instances of their subtypes without altering the correctness of that program 8 Rectangle Square
- 9. SOLID • Interface segregation principle • Many client-specific interfaces are better than one general-purpose interface 9
- 10. SOLID • Dependency inversion principle • Abstractions should not depend on details • Don’t depend on anything concrete • Work with interfaces 10
- 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. Which Components? • Methods • Classes • Packages • Modules • System 13
- 14. 14 Why SRP ?
- 15. Why SRP? • Organize the code 15 George A. Miller
- 16. Why SRP? • A place for everything and everything in its place 16
- 17. Why SRP? • Less fragile code • Low coupling • High cohesion 17
- 18. Why SRP? • Easier code changes (Refactoring) 18
- 19. Why SRP? • Easier naming • The smaller and more focused class, it will be easier to name 19
- 20. Why SRP? • Maintainability • Testability and easier debugging 20
- 22. Recognizing By Structure • Class / method is too long 22 Class: LOC > 250 Bad
- 23. Recognizing By Structure • Too many dependencies (fields / parameters) 23 Class Dependency 1 Dependency 2 Dependency 3 Dependency 4 Dependency 5 Dependency 6
- 24. Recognizing By Structure • Low cohesion 24
- 25. Recognizing By Structure • Description / name needs: “AND” • Generic name: “EmployeeManager” 25 void calculateAndSend(…)
- 26. Recognizing By Structure • A method with many levels 26 if while
- 27. Recognizing By Behavior • Class needs to be changed for more than one behavioral change 27
- 28. Recognizing By Behavior • Complicated test 28 when(…).then(…); when(…).then(…); when(…).then(…); when(…).then(…); when(…).then(…); when(…).then(…);
- 29. Recognizing By Behavior • Change here, break there • Test may be broken elsewhere • The “shotgun effect” 29
- 30. Recognizing By Behavior • Unable to encapsulate the module 30
- 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. Develop for SRP • Testable code • TDD 33 Test CodeRefactor
- 34. Develop for SRP • Code quality metrics • Coverage • SONAR 34
- 35. Develop for SRP • Use other principles • High cohesion • Decrease coupling • Interfaces • Real encapsulation • Law of Demeter 35
- 36. Develop for SRP 36 Keep it simple, stupid! Keep it simple and short! Keep it simple, short and specific!
- 37. Develop for SRP • Naming • Think about it • Role play your entities • Longer and more focused name 37
- 38. Develop for SRP • Extract method • Extract class 38
- 39. Develop for SRP • Refactor mercilessly • Use design patterns • Keep modularization clear 39
- 40. Example 40 Precise name (method, class) Short class, 35 lines High cohesion
- 41. Conclusion • OOD • Clean code • Better practice 41 Do 1 thing A class should have one reason to change! SRP
- 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
- 44. Q & A 44