The SOLID principles

The SOLID principles explained in detail for the development of maintainable and robust applications

9 min readJan 9

Object-oriented programming led to the emergence of a new way of designing applications.

It gave developers the ability to combine data for the same purpose into a single class so common functionality was encapsulated within the application unlike functional programming or other paradigms. However, this did not mean the end of applications that were badly architectured or difficult to maintain.

In order to combat this, Robert C. Martin proposed 5 principles in order to make it easier for developers to create applications that are easy to read and, most importantly, maintainable in the long run. These 5 principles come together in the acronym SOLID:

S: Single Responsibility Principle
Or: Open-Closed Principle
L: Liskov Substitution Principle
I: Interface Segregation Principle
D: Dependency Inversion Principle

In this article, you’ll discover what each means and its implications for application design.

Let’s see them!

Single Responsibility Principle

A class should have only one function.

A class should be responsible for only one thing. The moment it acquires more responsibility, it becomes coupled, something that is not desirable if you want to ensure the maintenance of the application. This is because a change in one of your responsibilities can affect the other and vice versa.

Of course this principle does not apply only to classes, but also to other software components as well as to the famous microservices.

For example, suppose this class:

class Vehicle {
     constructor(identifier: string){ }
     getVehicleIdentifier() { }
     saveVehicle(v: Vehicle) { } 
     getVehicle(identifier: string): Vehicle { }
}