Software Design - Single Responsibility Principle - with examples


For me, Single Responsibility Principle (SRP) is the most important design principle.

What is Single Responsibility Principle? How do you use it? How does it help with making your software better? Let’s get started.

We learn

  • What is the Single Responsibility Principle?
  • How do you apply this principle in developing and designing software applications?

Software Design Principles

This is the fourth article in a series of articles on important Software Design Principles:

What Is The Single Responsibility Principle (SRP)?

As the term says, this principle is all about having single responsibility.

In any software system, this principle is applicable at multiple levels

  • a variable
  • a method
  • a class
  • a package
  • a component
  • application layers or
  • the entire application itself

SRP For Methods

Any method that you write should have a single responsibility - it should either be a high-level method, or a low-level one. Only when a method has a single responsibility, you will be able to give it an appropriate name.

SRP For Classes

“A class should have one, and only one reason to change”

Let’s now have a look at a few examples of classes that violate this principle, and then look at how to correct the violation.

Example 1: The Task class


	public class Task {
		public void downloadFile(Strign location) {
			//...
		}

		public void parseTheFile(File file) {
			//...
		}

		public void persistTheData(Data data) {
			//...
		}
	}

Does the class Task adhere to the single responsibility principle? Not at all, because it does a lot of different things:

  • downloadFile() downloads the file, by communicating over the internet
  • parseTheFile() parses the file contents
  • persistTheData() saves the data into a database

A better solution would be to have separate classes for each of the responsibilities currently taken up by Task. Here is one such solution.

Identifying The Low-level Classes


	public class FileDownloader {
		public void downloadFile() {
			//...
		}
	}

	public class DataParser {
		public void parseData() {
			//...
		}
	}

	public class DatabaseStorer {
		public void storeIntoDatabase() {
			//...
		}
	}

  • FileDownloader only downloads the file from the internet
  • DataParser only parses the downloaded file
  • DatabaseStorer only stores the parsed data, into the database

These are all low-level classes here.

Adding A High-Level Class

	public class DownloadAndStore {
		public void doEverything() {
			new FileDownloader().downloadFile();
			new DataParser().parseData();
			new DatabaseStorer().storeIntoDatabase();
		}
	}

Then, you can create a high-level class such as DownloadAndStore that invokes the functionality of these low-level classes to perform the complete task. Such an organization ensures that the low-level classes are reusable.

Example 2: The Employee Class

Consider next, the Employee class shown below:


	public class Employee {
		public Money calculatePay() {
			//...
		}
		public String reportHours() {
			//...
		}
		public void save() {
			//...
		}
	}

Employee concerns itself with not just calculating the pay of an employee, but also reporting hours for work, and saving these details to the database.

I will leave it as an exercise to fix the Employee class to adhere to SRP.

SRP For Components

Every enterprise application has parts of its functionality organized as Components. For example, have a look at the diagram below:

image info

Here, the following components are of note:

  • Security component takes care of user authentication and authorization. Designing such a component helps abstract applications from the low-level security details. All microservices can interact with this component to find out if a user has access.
  • The Logging component - does the low level logging functionality
  • The Archetype component - Can be used to create new microservices

Each of these components have a single responsibility. If the Security component takes care of logging, it would become less reusable. Therefore, at the component level, a well-defined single responsibility is highly desirable.

Using SRP For Common Infrastructure

image info

In the diagram shown above, you can identify the following infrastructure components:

  • Naming Service - Has the responsibility to retrieve the service location based on its name
  • API Gateway - All requests go through the API Gateway. Common features like authentication, logging, rate limiting can be implemented in an API Gateway.
  • Centralized Logging - Centralized store for logs from all microservices so that we can easily debug problems

Even with these sub-systems, a single responsibility for each of them is most desirable.

Using SRP For Application Layering

Single responsibility is also an important factor in how you layer your application. Have a look at the following conceptual layers in a web application:

image info

  • Web Layer: All functionality concerned with direct user interaction sits here
  • Business Layer: Houses the core business logic
  • Data layer: All the functionality dealing with storing and retrieving data goes here

If you had the need to talk to other systems, there would have been an additional Enterprise Messaging Layer added onto this setup.

Summary

In this article, we talked about the Single Responsibility Principle. It is applicable at multiple levels to the parts of an application. This includes methods, classes, packages, components and application layers. With regards to classes, at a low level it means a class has only one reason to change.

In general, Single Responsibility ensures high cohesion, low coupling and enhanced reusability.

Do check out our video on this:

image info

10 Step Reference Courses

Image Image Image Image Image

in28Minutes is creating amazing solutions for you to learn full stack and the cloud - Docker, Kubernetes, AWS, React, Angular etc. Click here for the complete catalogue of 30 Courses.

Related Posts

Spring Boot Tutorials for Beginners

At in28Minutes, we are creating a number of tutorials with videos, articles & courses on Spring Boot for Beginners and Experienced Developers. This resources will help you learn and gain expertise at Spring Boot.

Spring and Spring Boot Video Tutorials for Beginners

At in28Minutes, we are creating a number of tutorials with videos, articles & courses on Spring Boot for Beginners and Experienced Developers. Here's a list of video tutorials and courses for you

Software Design - Separation Of Concerns - with examples

Software architects and programmers love having Seperation of Concerns. What is it? Why is it important? Let's get started.

Object Oriented Software Design - Solid Principles - with examples

Software design is typically complex. Object oriented design takes it to the next level. There are a number of design patterns and other stuff to be aware of. Can we make things simple? What are the goals to aim for when you are doing object oriented design? SOLID Principles is a great starting point for Object Oriented Design.

Software Design - Open Closed Principle - with examples

Open Closed Principle is one of the SOLID Principles. You want your code to be easily extended. How do you achieve it with minimum fuss? Let's get started.

Software Design - What is Dependency Inversion Principle?

Dependency Inversion Principle is one of the important SOLID Principles. Dependency Inversion Principle is implemented by one of the most popular Java frameworks - Spring. What is it all about? How does it help you design good applications?

Introduction to Four Principles Of Simple Design

With agile and extreme programming, the focus is on keeping your design simple. How do you keep your design simple? How do you decide whether your code is good enough?

REST API Best Practices - With Design Examples from Java and Spring Web Services

Designing Great REST API is important to have great microservices. How do you design your REST API? What are the best practices?

Designing REST API - What is Code First Approach?

Designing Great REST API is important to have great microservices. Code First approach focuses on generating the contract from code. Is it the best possible approach?

Designing REST API - What is Contract First?

Designing Great REST API is important to have great microservices. Contract First approach helps you in designing a great contract before implementing it. However, it does not come easy!