SOLID Introduction

The SOLID principles

The 5 SOLID principles of software application design are:

• S – Single Responsibility Principle (SRP)
• O – Open/Closed Principle (OCP)
• L – Liskov Substitution Principle (LSP)
• I – Interface Segregation Principle (ISP)
• D – Dependency Inversion Principle (DIP)

Among the objectives of taking these 5 principles into account when writing code we find:

• Create effective software: that fulfills its mission and that is robust and stable.
• Write a clean and flexible code in the face of changes: that can be easily modified according to need, that is reusable and maintainable.
• Allow scalability: that accepts to be expanded with new functionalities in an agile way.

In short, develop quality software.

In this sense, the application of the SOLID principles is closely related to the understanding and use of design patterns that will allow us to maintain high cohesion and, therefore, low software coupling.

What are cohesion and coupling?

They are two very relevant concepts when designing and developing software. Let's see what they consist of.

COUPLING

Coupling refers to the degree of interdependence that two software units have with each other, understanding by software units: classes, subtypes, methods, modules, functions, libraries, etc.

If two software units are completely independent of each other, we say that they are decoupled.

COHESION

Software cohesion is the degree to which different elements of a system stay together to achieve a better result than if they worked separately. It refers to the way we can group various software units together to create a larger unit.

1. Principle of Single Responsibility

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

The S in the acronym we are talking about today stands for Single Responsibility Principle (SRP). According to this principle “a class should have one, and only one, reason to change”. It is this, precisely, "reason to change", what Robert C. Martin identifies as "responsibility".

The Single Responsibility principle is the most important and fundamental of SOLID, very simple to explain, but the most difficult to follow in practice.

Bob himself sums up how to do it: “Gather together the things that change for the same reasons. Separate those things that change for different reasons ” , that is:“ Gather things that change for the same reasons. Separate those that change for different reasons ”.

2. Open / Closed Principle

“You should be able to extend a classes behavior, without modifying it.”

The second SOLID principle was formulated by Bertrand Meyer in 1988 in his book "Object Oriented Software Construction" and says: "You should be able to extend the behavior of a class, without modifying it." In other words: the classes you use should be open to be extended and closed to be modified.

In his blog Robert C. Martin defended this principle that a priori may seem like a paradox. It is important to take into account the Open / Closed Principle (OCP) when developing classes, libraries or frameworks.

3. Liskov Substitution Principle

“Derived classes must be substitutable for their base classes.”

The L in SOLID refers to the last name of its creator, Barbara Liskov, and says that "derived classes must be substitutable for their base classes"

This means that objects must be able to be replaced by instances of their subtypes without altering the correct functioning of the system or what is the same: if in a program we use a certain class, we should be able to use any of its subclasses without interfering with the functionality of the program. .

According to Robert C. Martin, breaching the Liskov Substitution Principle (LSP) also implies violating the Open / Closed principle.

4. Principle of Interface Segregation

“Make fine grained interfaces that are client specific.”

In SOLID Principle 4, Uncle Bob suggests: "Make interfaces that are specific to one type of customer," that is, for a specific purpose.

In this sense, according to the Interface Segregation Principle (ISP), it is preferable to have many interfaces that define few methods than to have an interface forced to implement many methods that it will not use.

5. Principle of Dependency Investment

“Depend on abstractions, not on concretions.”

We come to the last principle: "It depends on abstractions, not on concrete classes."

Thus, Robert C. Martin recommends:

1. High-level modules> should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions shouldn't depend on details. The details should depend on the abstractions.

The objective of the Dependency Inversion Principle (DIP) is to reduce dependencies between code modules, that is, to achieve low coupling of classes.

Criticism of SOLID

The field of software development is an area of ​​continuous debate and SOLID is not left out of the controversy.

Although these five principles are considered by many as a fundamental basis for good development or at least as a guide to take into account, there are not few professionals who criticize the SOLID principles.

They accuse them of being ambiguous, confusing, of complicating the code, of delaying the development process, and even brand them as totally wrong and unnecessary.