Cidenet+Blog+Clean Dev Practices+S.O.L.I.D. Clean Development Best Practices (Part 1)

S.O.L.I.D. Clean Development Best Practices (Part 1)

Good Clean Development Practices S.O.L.I.D.

Carlos Bermúdez
Director of Architecture

Jeffrey Tobón Cataño
Development analyst

Cidenet’s Architecture Area seeks to promote the best practices of Clean Development, and to advance in technical excellence. For this reason, we share the S.O.L.I.D. principles, a set of guidelines to make it easier for developers to create readable, maintainable and reusable programs.

Although these principles are quite powerful, you don’t have to obsess over wanting to adhere to them at every point of development. These principles are not rules that must be applied to the letter, they are simply guidelines that can be followed to improve the quality of the code.

This acronym was coined by Michael Feathers based on a publication by Robert C. Martin (Bob) in 2000 called “Design Principles and Design Patterns”.

The five principles 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)
– Dependency Inversion Principle (DIP)

In this first installment of the blog, we are going to expose the first two letters.

Single Responsibility Principle

The Single Responsibility Principle (SRP) establishes that a class, component, module, or microservice must have a single responsibility (specific and bounded task). This principle is perhaps the most crucial and fundamental of the five, very simple to explain, but the most difficult to follow in practice. “Bob” himself sums up how to do it:

“Gather things that change for the same reasons. Separate those that change for different reasons”.


  • Facilitates code testing implementation.
  • It encourages low coupling and high cohesion (fewer responsibilities, fewer dependencies).
  • Promotes order in projects (classes, packages, modules, etc).

Let’s see an example:

Multiple responsibilities (the process of login and sending of mail), violates the principle:

We separate these responsibilities by taking the sendEmail method to another class where its only responsibility will be to send messages.

Open / closed Principle

It was formulated by Bertrand Meyer in 1988 in his book “Object-Oriented Software Construction”,  where it says “You should be able to extend the behavior of a class, without modifying it”. In other words: the classes, modules, and functions that you use should be open to being extended and closed to be modified.

The Open / Closed Principle (OCP), which a priori may seem like a paradox, is crucial to take into account when developing classes, libraries, or frameworks. It is essential to keep a balance when following this principle, since if it is exaggerated, we will result in a code that is unreadable and difficult to maintain.


  • It facilitates the addition of new functionalities, preventing breaking existing functionalities.
  • It provides the necessary order to add new functionalities.
  • It makes testing easy, both for current code and for new features.

Let’s see an example:

We want to create an application that allows us to draw a character from the Terminator saga, in this case, “Carl” a T-800:

Now we need to paint other characters more, it would be something like:

As we can see in the previous code, for each character a new else if must be added to the code. To solve this, we create an Interface ICharacter, which defines the draw method. Then each character must implement that interface. In this way, each character, regardless of who it is, can draw itself.

We hope this information has been helpful. In the next installment, we will talk about the following three principles.

Contact us

Allow us to contact you

    Medellín - Colombia

  • Carrera 69 #49A - 11 Barrio Suramericana
  • (+57) 312 8475682

    United States

  • 1200 Colorado Blvd, Denver Colorado 80220
  • (+1) 7723619239