1. S. Single Responsibility Principle O. L. I. D.1

2. 1 2 3 4 5 Content Definition Advantages Example
How to recognize a break of S.R.P? 5
How to make the design compliant with the S.R.P? 2

3. 01
Definition

4. The single responsibility principle - definition
Single Responsibility Principle is one of the five principles of SOLID Design Principles.
From Wikipedia:
…In object-oriented programming, 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….
From Clean Code:
A class or module should have one, and only one, reason to change.

5. What the definition means
When we design our classes, we should take care that one class at the most is responsible for doing one task or functionality among the whole set of responsibilities that it has. And only when there is a change needed in that specific task or functionality should this class be changed.
How to recognize it?
SRP looks simple on the first glance, but it is, probably, the most difficult SOLID principle to follow in practice.
Following SRP is difficult because “reasons to change” become certain only in the future, when requirements actually change. At design time, all we can do is estimate which requirements are likely to change and which are stable.
One effective way of identifying “reasons to change” is to learn about the business domain that is targeted by the application. Since most of the requirements come from business domain, there is a high probability that any instability in that domain will propagate into the requirements.

6. 02
Advantages

7. Advantages of S.R.P Organize the code
Less fragile When a class has more than one reason to be changed, it is more fragile. A change in one location might lead to some unexpected behavior in totally other places.
Low Coupling/High Cohesion More responsibilities lead to higher coupling. Higher coupling leads to more dependencies, which is harder to maintain. Cohesion refers to the degree to which the elements inside a class belong together.
Code Changes Refactoring is much easier for a single responsibility module.
Maintainability It’s obvious that it is much easier to maintain a small single purpose class, then a big monolithic one.
Testability A test class for a ‘one purpose class’ will have less test cases (branches). If a class has one purpose it will usually have less dependencies, thus less mocking and test preparing. The “self documentation by tests” becomes much clearer.
Easier Debugging In a single responsibility class, finding the bug or the cause of the problem, becomes a much easier task.

8. 03
Example

9. What needs to have single responsibility?
Each part of the system:
The methods
The classes
The packages
The modules

10. 04 How to recognize a break of Single Responsibility Principle?

11. How to recognize a break of S. R. P?
Class Has Too Many Dependencies
A constructor with too many input parameters implies many dependencies (hopefully you do inject dependencies). Another way too see many dependencies is by the test class. If you need to mock too many objects, it usually means breaking the SRP.
Method Has Too Many Parameters
Same as the class’s smell. Think of the method’s parameters as dependencies.
The Test Class Becomes Too Complicated
If the test has too many variants, it might suggest that the class has too many responsibilities. It might suggest that some methods do too much.
Class / Method is Long
If a method is long, it might suggest it does too much. Same goes for a class.
Descriptive Naming
If you need to describe what your class / method / package is using with the AND world, it probably breaks the SRP.
Change In One Place Breaks Another
If a change in the code to add a new feature or simply refactor broke a test which seems unrelated, it might suggest a breaking the SRP.
Shotgun effect
If a small change makes a big ripple in your code. If you need to change many locations it might suggest, among other smells, that the SRP is broken. 11

12. 05
How to make the design
compliant with the S.R.P?

13. How to make the design compliant with the S.R.P?
Awareness
This is a general suggestion for clean code. We need to be aware of our code. We need to take care. As for SRP, we need to try and catch as early as we can a class that is responsible for too much. We need to always look for a ‘too big method’.
Testable Code
Write your code in a way that everything can be tested. Then, you will surly want that your tests be simple and descriptive.
Code Coverage Metrics
Sometimes, when a class does too much, it won’t have 100% coverage at first shot. Check the code quality metrics. 13

14. Thank you for your attention
Copyright: © 2019 Seavus. All rights reserved. | | |