Single Responsibility Principle

1,697
-1

Published on

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.

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

No Downloads
Views
Total Views
1,697
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
32
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 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)
  • Single Responsibility Principle

    1. 1. Design around the… Single Responsibility Principle By Eyal Golan
    2. 2. Agenda 1. SOLID 2. SRP overview 3. Why SRP? 4. Recognizing SRP violation 5. Develop for SRP 6. Summarize 2
    3. 3. 3
    4. 4. S O L I D • Robert C. Martin – Uncle Bob • http://en.wikipedia.org/wiki/SOLID_(objectoriented_design) 4
    5. 5. SOLID • Single responsibility principle • A class should have only a single responsibility 5
    6. 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. 7. SOLID • Liskov substitution principle • Replace objects with instances of their subtypes without altering the correctness of that program Rectangle Square 7
    8. 8. SOLID • Interface segregation principle • Many client-specific interfaces are better than one general-purpose interface 8
    9. 9. SOLID • Dependency inversion principle • Abstractions should not depend on details • Don’t depend on anything concrete • Work with interfaces 9
    10. 10. 10
    11. 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
    12. 12. Which Components? • • • • • Methods Classes Packages Modules System 12
    13. 13. 13
    14. 14. Why SRP? • Organize the code George A. Miller 14
    15. 15. Why SRP? • A place for everything and everything in its place 15
    16. 16. Why SRP? • Less fragile code • Low coupling • High cohesion 16
    17. 17. Why SRP? • Easier code changes (Refactoring) 17
    18. 18. Why SRP? • Easier naming • The smaller and more focused class, it will be easier to name 18
    19. 19. Why SRP? • Maintainability • Testability and easier debugging 19
    20. 20. 20
    21. 21. Recognizing By Structure • Class / method is too long 21
    22. 22. Recognizing By Structure • Too many dependencies (fields / parameters) Dependency 3 Dependency 4 Dependency 2 Dependency 1 Dependency 5 Class Dependency 6 22
    23. 23. Recognizing By Structure • Low cohesion 23
    24. 24. Recognizing By Structure • Description / name needs: “AND” • Generic name: “EmployeeManager” 24
    25. 25. Recognizing By Structure • A method with many levels 25
    26. 26. Recognizing By Behavior • Complicated test 26
    27. 27. Recognizing By Behavior • Change here, break there • Test may be broken elsewhere • The “shotgun effect” 27
    28. 28. Recognizing By Behavior • Unable to encapsulate the module 28
    29. 29. 29
    30. 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. 31. Develop for SRP • Testable code Test • TDD Refactor Code 31
    32. 32. Develop for SRP • Code quality metrics • Coverage • SONAR 32
    33. 33. Develop for SRP • Use other principles • • • • High cohesion Decrease coupling Interfaces Real encapsulation • Law of Demeter 33
    34. 34. Develop for SRP Keep it simple and short! 34
    35. 35. Develop for SRP • Naming • Think about it • Role play your entities • Longer and more focused name 35
    36. 36. Develop for SRP • Extract method • Extract class 36
    37. 37. Develop for SRP • Refactor mercilessly • Use design patterns • Keep modularization clear 37
    38. 38. Example Short class, 35 lines Precise name (method, class) High cohesion 38
    39. 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. 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
    41. 41. Simple, Isn’t It? 41
    42. 42. Q&A 42
    43. 43. Eyal Golan 43

    ×