Design around the Single Responsibility Principle (SRP
•Als PPTX, PDF herunterladen•
7 gefällt mir•4,686 views
This presentation is based on a blog post I made: http://eyalgo.com/2014/02/01/the-single-responsibility-principle/ More details are in that blog post. I had a presentation at work with these slides.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Ähnlich wie Design around the Single Responsibility Principle (SRP
Ähnlich wie Design around the Single Responsibility Principle (SRP (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Design around the Single Responsibility Principle (SRP
- 1. Design around the… Single Responsibility Principle By Eyal Golan
- 2. Agenda 1. SOLID 2. SRP overview 3. Why SRP? 4. Recognizing SRP violation 5. Develop for SRP 6. Summarize 2
- 3. 3
- 4. S O L I D • Robert C. Martin – Uncle Bob • http://en.wikipedia.org/wiki/SOLID_(objectoriented_design) 4
- 5. SOLID • Single responsibility principle • A class should have only a single responsibility 5
- 6. 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…” 6
- 7. SOLID • Liskov substitution principle • Replace objects with instances of their subtypes without altering the correctness of that program Rectangle Square 7
- 8. SOLID • Interface segregation principle • Many client-specific interfaces are better than one general-purpose interface 8
- 9. SOLID • Dependency inversion principle • Abstractions should not depend on details • Don’t depend on anything concrete • Work with interfaces 9
- 10. 10
- 11. 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 11
- 13. 13
- 14. Why SRP? • Organize the code George A. Miller 14
- 15. Why SRP? • A place for everything and everything in its place 15
- 16. Why SRP? • Less fragile code • Low coupling • High cohesion 16
- 17. Why SRP? • Easier code changes (Refactoring) 17
- 18. Why SRP? • Easier naming • The smaller and more focused class, it will be easier to name 18
- 19. Why SRP? • Maintainability • Testability and easier debugging 19
- 20. 20
- 21. Recognizing By Structure • Class / method is too long 21
- 22. Recognizing By Structure • Too many dependencies (fields / parameters) Dependency 3 Dependency 4 Dependency 2 Dependency 1 Dependency 5 Class Dependency 6 22
- 23. Recognizing By Structure • Low cohesion 23
- 24. Recognizing By Structure • Description / name needs: “AND” • Generic name: “EmployeeManager” 24
- 25. Recognizing By Structure • A method with many levels 25
- 26. Recognizing By Behavior • Complicated test 26
- 27. Recognizing By Behavior • Change here, break there • Test may be broken elsewhere • The “shotgun effect” 27
- 28. Recognizing By Behavior • Unable to encapsulate the module 28
- 29. 29
- 30. Develop for SRP • Awareness • The state or ability to perceive, to feel, or to be conscious of events, objects, or sensory patterns 30
- 31. Develop for SRP • Testable code Test • TDD Refactor Code 31
- 32. Develop for SRP • Code quality metrics • Coverage • SONAR 32
- 33. Develop for SRP • Use other principles • • • • High cohesion Decrease coupling Interfaces Real encapsulation • Law of Demeter 33
- 34. Develop for SRP Keep it simple and short! 34
- 35. Develop for SRP • Naming • Think about it • Role play your entities • Longer and more focused name 35
- 36. Develop for SRP • Extract method • Extract class 36
- 37. Develop for SRP • Refactor mercilessly • Use design patterns • Keep modularization clear 37
- 38. Example Short class, 35 lines Precise name (method, class) High cohesion 38
- 39. Conclusion • OOD • Clean code • Better practice SRP Do 1 t h i A s o c c l a s s h o u l d h a v e ne r e a s on t o h a n g e ! 39
- 40. Resources • http://butunclebob.com/ArticleS.UncleBob.Principles OfOod • Uncle Bob about SRP • http://www.codinghorror.com/blog/2007/03/curlyslaw-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-singleresponsibility-principle/ • My blog post about SRP 40
- 42. Q&A 42
- 43. Eyal Golan 43
Hinweis der Redaktion
- And more…Not only SRP but some technics around it
- SOLID Principle as a part of good OOD
- SOLID was introduced by Robert C. Martin – Uncle BobThis are PRINCIPLES !
- SRP – We’ll discuss in more details in following slides
- OCPAn entity can allow its behavior to be modified without altering its source codeNew or changed features would require that a different class be createdExample: if shape is circle the area = … else if shape is square then area = …
- LSPIf S is a subtype of T, then objects of type T may be replaced with objects of type SNew derived classes just extend without replacing the functionality of old classes.Square class that derives from a Rectangle classIf a Square object is used in a context where a Rectangle is expected, unexpected behavior may occur because the dimensions of a Square cannot (or rather should not) be modified independently
- ISPSmall and specific interfacesClient should not be depend upon an interface it does not need ISPstates that no client should be forced to depend on methods it does not useISP is intended to keep a system decoupled
- While developing, code for interfaces and not concreteI find that TDD really helps me achieve that
- At each level of the system, we need to take care that any component has one responsibilitySymbol of “everything”
- 7+-2: Limits on Our Capacity for Processing Information Cognitive psychologist: George A. Mille
- When we were young we ordered our room like the pictureOur parents taught us betterOur experience taught us even better
- Change due needs of C might break B.
- Refactoring is much easier for a single responsibility module
- You will usually end up with longer, more precise name for your classes
- Simpler tests for simple code
- We’re going to see some hints (smell) of breaking the SRPBy structure and then by behavior of the code
- A class should be longer than 200-250 LOC as a rule of thumb
- Some tips on how to develop in order to apply the SRPMost of them will move you towards more OOD / SOLID principles
- This is a general tip for being craftsman and professional
- TDD will show when a class does too muchThe code which is designed by TDD will usually evolve to code that holds many principles
- Enough said. Let’s finish !
- If you can’t find a focused name (and handler / manager are not focused), try to make the module more focused
- Refactorrefactorrefactor
- OOD , Clean Code, Better practice – SRP is helping to achieve them
- I chose simple items to show how they things can be extremely good when doing just one thing (+SMS)