Single Responsibility Principle of SOLID (BPD)

According to Robert C. Martin (Uncle Bob), the Single Responsibility Principle (SRP) is:

A module must be responsible to one, and only one, actor.

In this article, we will understand what this statement means studying the first principle from SOLID.

About SOLID

It was introduced by Robert C. Martin (Uncle Bob) in the early 2000s. There are 5 principles that provide a foundation for good software design:

[x] – Single Responsibility Principle (SRP)

[  ] – Open-Closed Principle (OCP)

[  ] – Liskov Substitution Principle (LSP)

[  ] – Interface Segregation Principle (ISP)

[  ] – Dependency Inversion Principle (DIP)

Repeat and Repeat 🔂

Studying our history, we can remember the Industrial Revolution, which occurred in the 18th and 19th centuries, where companies improved their productivity. Charlie Chaplin presented this to us so well in his films.

Basically, companies were divided into sectors, and with that, the quality of the products improved significantly.

To make this division, they divided in groups (actors), and each group just did only one thing.

A module must be responsible for one, and only one, actor.

It’s similar to the SRP principle because we need to know the actors to define where the actions (functions) will stay.

What is module?

A module is a cohesive set of functions and data structures (such as classes). The term “cohesive” refers to the the SRP:

Cohesion is the force that ties the responsible code to a single actor – Uncle Bob

Clean Code

In Clean Code we follow the instruction:

A function must do only one thing

Example:

// bad code :(
function processPay(manager: boolean) {
  if (manager) ...
  else ...
}

// better code :)
function processPayManager() { ... }
function processPay() { ... }

This is not an example of the SRP. Remember:

A module must be responsible to one, and only one, actor.

A module is like a class. While the concept is similar, there is a difference: one pertains to the class, and the other pertains to the function.

 

Single Responsibility Principle

The goal of using this technique is to make your software easier to implement and prevent unexpected side effects from future changes, always considering the actor.

Remember the solution from the last article using FACADE and SRP:

  • Creating 3 different classes:
  • Actors:
    • CarRental
    • FlightBooking
    • HotelReservation
export class CarRental {
    rentCar() {
        console.log("Renting car...");
    }
}

export class FlightBooking {
    bookFlight() {
        console.log("Booking flight...");
    }
}

export class HotelReservation {
    bookRoom(): void {
        console.log("Booking room...")
    }
}
  • Creating Facade class:
import { CarRental } from "./car-rental";
import { FlightBooking } from "./flight-booking";
import { HotelReservation } from "./hotel-reservation";

export class TravelFacade {
    bookCompletePackage() {
        new FlightBooking().bookFlight();
        new HotelReservation().bookRoom();
        new CarRental().rentCar();
    }
}
  • Now we just create the index.ts:
import { TravelFacade } from "./travel/travel-facade";

new TravelFacade().bookCompletePackage()

Conclusion

Maybe you can contest this solution pointing out that all classes have only one function. This is a mistake. The number of functions needed to do this actions probably will be high and each of these class will have a lot of private functions.

In the next article, we will discuss the next item of SOLID (Open-Closed Principle).

Thanks! See you soon 🙂

Previous Article

#2 – Facade Design Pattern (BPD)

Leave a Reply