Buenas prácticas de Desarrollo Limpio S.O.L.I.D.

Carlos Bermúdez 
Director de Arquitectura

Jeffrey Tobón Cataño
Analista de Desarrollo

El Área de Arquitectura de Cidenet busca promover las buenas prácticas de desarrollo y avanzar en la excelencia técnica, por dicha razón, compartimos los principios S.O.L.I.D., un conjunto de directrices para facilitar, a los desarrolladores, la labor de crear programas legibles, mantenibles y reutilizables.

Aunque estos principios son bastante potentes, no hay que obsesionarse con querer cumplirlos en cada punto del desarrollo. Estos principios, no son reglas que se deban aplicar al pie de la letra, simplemente son directrices que se pueden seguir para mejorar la calidad del código.

Este acrónimo fue acuñado por Michael Feathers tomando como base una publicación realizada por Robert C. Martin (Bob) en el año 2000 llamada “Design Principles and Design Patterns”.

Los 5 principios son: 

  • 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)

En esta primera entrega del blog vamos a exponer las dos primeras letras.


Single Responsibility Principle

El Principio de Responsabilidad Única (SRP) establece que una clase, componente, módulo o microservicio debe tener una única responsabilidad (tarea específica y acotada). Este principio es quizás el más importante y fundamental de los cinco, muy sencillo de explicar, pero el más difícil de seguir en la práctica. El propio “Bob” resume cómo hacerlo:

Reúne las cosas que cambian por las mismas razones. Separa aquellas que cambian por razones diferentes.

Beneficios:

  • Facilita la implementación de pruebas del código.
  • Fomenta el bajo acoplamiento y alta cohesión (menos responsabilidades, menos dependencias).
  • Promueve el orden en los proyectos (clases, paquetes, módulos, etc).

Veamos un ejemplo:

Múltiples responsabilidades (proceso de login y envío de correo), viola el principio:

Separamos estas responsabilidades llevando el método sendEmail a otra clase donde su única responsabilidad será el envío de mensajes.


Open/closed Principle

Lo formuló Bertrand Meyer en 1988 en su libro “Object Oriented Software Construction”. donde dice  “Deberías ser capaz de extender el comportamiento de una clase, sin modificarla”. En otras palabras: las clases, módulos y funciones que usas deberían estar abiertas para poder extenderse y cerradas para modificarse.

El Principio Open/Closed (OCP) que a priori puede parecer una paradoja es importante tenerlo en cuenta a la hora de desarrollar clases, librerías o frameworks. Es importante mantener un balance a la hora de seguir este principio, ya que si se exagera tendremos como resultado un código ilegible y difícil de mantener.

Beneficios:

  • Facilita la adición de nuevas funcionalidades, previniendo romper las funcionalidades existentes.
  • Aporta el orden necesario para agregar nuevas funcionalidades.
  • Facilita las pruebas, tanto para el código actual como para las nuevas funcionalidades.

Veamos un ejemplo:

Queremos crear una aplicación que nos permita dibujar un personaje de la saga Terminator, en este caso a “Carl” un T-800:

Ahora necesitamos pintar otros personajes más, quedaría algo como:

Como podemos observar en el código anterior, por cada personaje se debe agregar un nuevo else if al código. Para solucionar esto, creamos una Interface ICharacter la cual define el método draw. Luego, cada personaje deberá implementar dicha interfaz. De esta forma, cada personaje, independientemente del que sea, se puede dibujar así mismo.

Esperamos que esta información haya sido provechosa. En la próxima entrega hablaremos de los tres siguientes principios.