Principles of SOLID

Introduction

Whenever I talk about SOLID, I like to think about what the name suggests. Understanding this, it becomes much easier to absorb the principles.

The very word SOLID, refers to something rigid, stable, that is, something that lasts and lasts in time. This is exactly what SOLID proposes to projects that apply its guidelines.

Let's now understand the principles of SOLID.

Single Responsability Principe (SOLID)

The principle of single responsibility says that a class should have only one reason to change it.

Purpose and that you do not put methods that have nothing to do with it, as this action prevents your class from getting inflated.

Let's look at the example of an inflated class:

public class Main {
    public static void main(String[] args) {

    }

    public void listClient() {}
    public void addClient() {}
    public void updateClient() {}
    public void deleteClient() {}
    public void notifyClient() {}
}

In this example above we have an inflated class with many methods. So how would she be applying the principles?

Each method should be separated into a single class

We will see:

public class Notify {
    public void notifyClient() {}
}

Open Closed Principle (S*O*LID)

The open or closed principle says it should be open for extension and closed for modification.

• open: It can be a class, module or function that will be extensible
• closed: Any resource that this entity receives, it must be closed for change. This should extend the entity.

The purpose of this is that any new resource it receives does not affect the application. This shields our code and avoids unwanted bugs that are often not discovered at the time.

Liskov Substitution Principle (SO*L*ID)

Liskov's Substitution Principle states that a derived class must be replaceable by a base class.

Interface Segregation Principle (SOL*I*D)

The principle of interface segregation has to do with an interface that has many methods, "inflated interfaces".

This principle says that we should break the interfaces into smaller interfaces, so that the client is not forced to depend on methods that they would not use.

Putting this principle into practice, it would be to divide into smaller interfaces, methods of a larger interface that don't make sense to be there.
Because we often see very large interfaces with several methods that are often not even used by the classes that implement these interfaces.

Dependency Inversion Principle (SOLI*D*)

Dependency inversion principle proposes the idea of decoupling modules from dependencies.

The modules that are built into a system are divided into two types:

• high level modules.
• low-level modules.

The principle says that high-level modules should not depend on low-level modules, as both should depend on abstractions and abstractions cannot depend on details.

But what does it all mean?

It means that high-level modules that have to do with business rules should be more abstract. Low-level modules, on the other hand, have to do with the internal tasks that it performs. An example of this has a user management would be the authentication part or querying the database