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

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

11. 11
Single
Responsibility
Principle

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

21. 21
Recognizing
SRP
Violation

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

31. 31
Develop For
SRP

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

43. Simple, Isn’t It?
43

44. Q & A
44

45. 45
Thank You
!
Eyal Golan
egolan74@gmail.com
Connect
@eyalgo_egolan
http://eyalgo.com/