About Eyal Golan

Eyal is a professional software engineer and an architect. He is a developer and leader of highly sophisticated systems in different areas, such as networking, security, commerce and more

The Single Responsibility Principle

Introduction

In this post I would like to cover the Single Responsibility Principle (SRP).
I think that this is the basis of any clean and well designed system.

What is SRP?

The term was introduced by Robert C. Martin. It is the ‘S’ from the SOLID principles, which are the basis for OOD. http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)Here’s the PDF paper for SRP by Robert C. Martin https://docs.google.com/file/d/0ByOwmqah_nuGNHEtcU5OekdDMkk/

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.

So if a class (or module) needs to be modified for more than one reason, it does more than one thing. I.e. has more than one responsibility.

Why SRP?

  • Organize the code
    Let’s imagine a car mechanic who owns a repair shop.
    He has many many tools to work with. The tools are divided into types; Pliers, Screw-Drivers (Phillips / Blade), Hammers, Wrenches (Tubing / Hex) and many more.How would it be easier to organize the tools?
    Few drawers with different types in each one of them?
    Or, many small drawers, each containing a specific type?Now, imagine the drawer as the module. This is why many small modules (classes) are more organized then few large ones.
  • 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
    More responsibilities lead to higher coupling.
    The couplings are the responsibilities.
    Higher coupling leads to more dependencies, which is harder to maintain.
  • Code Changes
    Refactoring is much easier for a single responsibility module.
    If you want to get the shotgun effect, let your classes have more responsibilities.
  • 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
    Since I started doing TDD and test-first approach, I hardly debug. Really.
    But, there come times when I must debug in order to understand what’s going on.
    In a single responsibility class, finding the bug or the cause of the problem, becomes a much easier task.

What needs to have single responsibility?

Each part of the system.

  • The methods
  • The classes
  • The packages
  • The modules

How to Recognize a Break of the SRP?

  • 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.
    My rule of thumb is that a class should not exceed 200-250 LOC. Imports included
  • Descriptive Naming
    If you need to describe what your class / method / package is using with the AND world, it probably breaks the SRP.
  • Class With Low Cohesion
    Cohesion is an important topic of its own and should have its own post.
    But Cohesion and SRP are closely related and it is important to mention it here.
    In general, if a class (or module) is not cohesive, it probably breaks the SRP.A hint for a non-cohesive class:
    The class has two fields. One field is used by some methods. The other field is used by the other methods.
  • 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.
  • Unable to Encapsulate a Module
    I will explain using Spring, but the concept is important (not the implementation).
    Suppose you use the @Configuration or XML configuration.
    If you can’t encapsulate the beans in that configuration, it should give you a hint of too much responsibility.
    The Configuration should hide any inner bean and expose minimal interfaces. If you need to change the Configuration due to more than one reason, then, well, you know…

How to make the design compliant with the Single Responsibility Principle

The suggestions below can apply to other topics of the SOLID principles. They are also good for any Clean Code suggestion.
But here they are aimed for the Single Responsibility Principle.

  • 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.
  • TDD
    (I am not going to add anything here)
  • Code Coverage Metrics
    Sometimes, when a class does too much, it won’t have 100% coverage at first shot.
    Check the code quality metrics.
  • Refactoring and Design Patterns
    For SRP, we’ll mostly do extract-method, extract-class, move-method.
    We’ll use composition and strategy instead of conditionals.
  • Clear Modularization of the System
    When using a DI injector (Spring), I think that Configuration class (or XML) can pinpoint the modules design. And modules’ single responsibility.
    I prefer to have several small to medium size of configuration files (XML or Java) than having one big file / class.
    It helps see the responsibility of the module and easier to maintain.
    I think that the configuration approach of injection has an advantage of annotation approach. Simply because the Configuration approach put the modules in the spotlight.

Conclusion

As I mentioned in the beginning of this post, I think that Single-Responsibility-Principle is the basis of a good design.
If you have this principle in your mind while designing and developing, you will have a simpler more readable code.
Better design will be followed.

One Final Note

As always, one needs to be careful on how to apply practices, code and design. Sometimes we might do over-work and make simple things over complex. So a common sense must be applied at any refactor and change.
 

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


× 8 = eight



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close