Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Single Responsibility Principle
By Eyal Golan
About Me
2
Senior Java developer and agile practitioner.
Practicing TDD, clean code. Software craftsmanship
advocate.
Tech...
Agenda
1. SOLID
2. SRP overview
3. Why SRP?
4. Recognizing SRP violation
5. Develop for SRP
6. Summarize
3
4
• Robert C. Martin – Uncle Bob
• http://en.wikipedia.org/wiki/SOLID_(object-
oriented_design)
5
Single responsibility prin...
SOLID
• Single responsibility principle
• A class should have only a single
responsibility
6
SOLID
• Open/closed principle
• Open for extension, but closed for
modification
• Alistair Cockburn: “…Identify points of ...
SOLID
• Liskov substitution principle
• Replace objects with instances of their
subtypes without altering the correctness ...
SOLID
• Interface segregation principle
• Many client-specific interfaces are better
than one general-purpose interface
9
SOLID
• Dependency inversion principle
• Abstractions should not depend on details
• Don’t depend on anything concrete
• W...
11
Single
Responsibility
Principle
Single Responsibility Principle
• Wikipedia
• …the single responsibility principle states that every class
should have a s...
Which Components?
• Methods
• Classes
• Packages
• Modules
• System
13
14
Why SRP ?
Why SRP?
• Organize the code
15
George A. Miller
Why SRP?
• A place for everything and
everything in its place
16
Why SRP?
• Less fragile code
• Low coupling
• High cohesion
17
Why SRP?
• Easier code changes (Refactoring)
18
Why SRP?
• Easier naming
• The smaller and more focused class, it will
be easier to name
19
Why SRP?
• Maintainability
• Testability and easier debugging
20
21
Recognizing
SRP
Violation
Recognizing By Structure
• Class / method is too long
22
Class:
LOC > 250
Bad
Recognizing By Structure
• Too many dependencies (fields /
parameters)
23
Class
Dependency 1
Dependency 2
Dependency 3 Dep...
Recognizing By Structure
• Low cohesion
24
Recognizing By Structure
• Description / name needs: “AND”
• Generic name: “EmployeeManager”
25
void calculateAndSend(…)
Recognizing By Structure
• A method with many levels
26
if
while
Recognizing By Behavior
• Class needs to be changed for more
than one behavioral change
27
Recognizing By Behavior
• Complicated test
28
when(…).then(…); when(…).then(…);
when(…).then(…);
when(…).then(…);
when(…)....
Recognizing By Behavior
• Change here, break there
• Test may be broken elsewhere
• The “shotgun effect”
29
Recognizing By Behavior
• Unable to encapsulate the module
30
31
Develop For
SRP
Develop for SRP
• Awareness
• The state or ability to perceive, to feel, or to
be conscious of events, objects, or sensory...
Develop for SRP
• Testable code
• TDD
33
Test
CodeRefactor
Develop for SRP
• Code quality metrics
• Coverage
• SONAR
34
Develop for SRP
• Use other principles
• High cohesion
• Decrease coupling
• Interfaces
• Real encapsulation
• Law of Deme...
Develop for SRP
36
Keep it simple, stupid!
Keep it simple and short!
Keep it simple, short and specific!
Develop for SRP
• Naming
• Think about it
• Role play your entities
• Longer and more focused name
37
Develop for SRP
• Extract method
• Extract class
38
Develop for SRP
• Refactor mercilessly
• Use design patterns
• Keep modularization clear
39
Example
40
Precise name
(method, class)
Short class,
35 lines
High cohesion
Conclusion
• OOD
• Clean code
• Better practice
41
Do 1 thing
A class should have one
reason to change!
SRP
Resources
• http://butunclebob.com/ArticleS.UncleBob.Principles
OfOod
• Uncle Bob about SRP
• http://www.codinghorror.com/...
Simple, Isn’t It?
43
Q & A
44
45
Thank You
!
Eyal Golan
egolan74@gmail.com
Connect
@eyalgo_egolan
http://eyalgo.com/
Upcoming SlideShare
Loading in …5
×

Single Responsibility Principle @ Clean Code Alliance Meetup

4,592 views

Published on

SRP in SOLID.
Presentation made at clean code alliance meetup in Israel.

Published in: Software
  • Be the first to comment

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/

×