S Single Responsibility Principle O L I D Content Definition 1 2 Advantages 3 4 How to recognize a break of SRP 5 How to make the design compliant with the SRP Example wwwseavuscom 01 Definition ID: 770795
Download Presentation The PPT/PDF document "S. Single Responsibility Principle" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
S. Single Responsibility Principle O. L. I. D.
Content Definition 1 2 Advantages 3 4 How to recognize a break of S.R.P? 5 How to make the design compliant with the S.R.P? Example www.seavus.com
01 Definition www.seavus.com
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 . www.seavus.com
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. www.seavus.com
02 Advantages www.seavus.com
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. www.seavus.com 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.
03 Example www.seavus.com
What needs to have single responsibility? Each part of the system: The methods The classes The packages The modules www.seavus.com
04 How to recognize a break of Single Responsibility Principle? www.seavus.com
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. 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. 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. Class / Method is Long If a method is long, it might suggest it does too much. Same goes for a class. 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. Descriptive Naming If you need to describe what your class / method / package is using with the AND world, it probably breaks the SRP. www.seavus.com Method Has Too Many Parameters Same as the class’s smell. Think of the method’s parameters as dependencies.
05 How to make the design compliant with the S.R.P ? www.seavus.com
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. www.seavus.com Code Coverage Metrics Sometimes, when a class does too much, it won’t have 100% coverage at first shot. Check the code quality metrics.
Thank you for your attention Copyright: © 2019 Seavus. All rights reserved. | www.seavus.com | info@seavus.com | sales@seavus.com