S.O.L.I.D. Principles, los necesitamos para testear bien (Parte 1/2)

– Post escrito por María Morales (@MaMoralesMC) y Noemí Navarro (@nnsanchez92).

En este post vamos a ampliar el conocimiento de los principios S.O.L.I.D. Ya se enumeraban en el blog en el año 2013 en este post. Te contamos brevemente sobre S.O.L.I.D, es un acrónimo creado por Tío Bob (Robert C. Martin, quizás le recuerdes de otros post del blog ya que se ha hablado de él en varias ocasiones) bajo el que se engloban cuatro principios que todo Diseño Orientado a Objetos debería seguir.

  • S (Single Responsability Principle) Es el Principio de Responsabilidad Única.
  • O (Open / Closed Principle) Es el Principio de Abierto Cerrado.
  • L (Liskov Substitution Principle) Es el Principio de Sustitución de Liskow.
  • I (Interface Segregation Principle) Es el Principio de Segregación de Interfaces.
  • D (Dependency Inversion Principle) Es el Principio de Inversión de Dependencias.

A continuación vamos a explicar cada uno de ellos, además vamos a ver la relación que tienen con el Testing (os dejamos también el enlace a los principios SOLID de Robert).

Single Responsibility Principle (SPR) – Principio de Responsabilidad Única

El principio SRP expone que una clase debería centrarse en hacer sólo una cosa, o tener una única responsabilidad. Esto no significa que deba tener sólo un método, tan sólo que todos los métodos deben estar centrados en un único objetivo, es decir, deben ser cohesivos.
Este principio está relacionado con la automatización de las pruebas, ya que si se incumple terminamos probando muchas clases que tienen dependencia entre sí (que esto también lo trataremos en el principio de inversión de dependencias), si por el contrario tenemos una sola clase con una sola responsabilidad probaremos de forma independiente.
A continuación os mostramos un dibujo de un diagrama UML donde se puede ver que rectángulo tiene varias responsabilidades y por tanto viola el principio de Responsabilidad Única.

captura-de-pantalla-2016-11-24-a-las-9-11-18
Más de una responsabilidad

Sin embargo en la siguiente imagen podemos ver las responsabilidades por separado, ya que aparece la entidad “Geometric Rectangle” con la función área.
Responsabilidades separadas
Responsabilidades separadas

Open Closed Principle (OCP) – Principio de Abierto/Cerrado

Bertrand Meyer puso el nombre a este principio (podéis leer más en este libro). El principio OCP explica de forma breve que las entidades (cuando hablamos de entidades nos referimos a clase, módulo, función, etc.) tienen que estar abiertas para poder ser extendidas, sin embargo tienen que estar cerradas para su modificación, es decir, el código fuente no se altere. Para seguir este principio se utiliza la abstracción.
El motivo por el cual se debe seguir este principio es que los cambios pueden influir negativamente en el código que funcionaba, entonces cuando aparecen funcionalidades nuevas se extiende el comportamiento de los módulos añadiendo código, pero no se cambia el código fuente que funciona ya que nadie está autorizado para ello.
Respecto al Testing, si para añadir código nuevo, hay que alterar el código que ya ha pasado el Testing Unitario, estamos en una mala práctica. A parte de pasar el Testing Unitario al código nuevo, tenemos que volver a lanzar las pruebas (lo que llamamos pruebas de regresión) y no deberán de fallar. De esta forma será más robusto porque no estamos cambiando el código ya probado.
Os dejamos un ejemplo explicativo de este principio. La primera imagen viola el principio de Abierto/Cerrado porque el cliente está ligado al servidor.

captura-de-pantalla-2016-11-24-a-las-9-15-37
Diseño que no se ajusta al principio abierto/cerrado

Sin embargo, la siguiente imagen muestra un diseño que sigue el principio de Abierto/ Cerrado porque utiliza la abstracción, de esta forma no se cambia el código.
Diseño que cumple el principio abierto/cerrado
Diseño que cumple el principio abierto/cerrado

Terminando…

Hasta aquí el post de hoy, lo hemos querido dividir en dos partes para que no sea demasiado largo. El viernes que viene publicaremos la segunda parte terminando así de explicar los principios S.O.L.I.D. restantes.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

1 comentario en “S.O.L.I.D. Principles, los necesitamos para testear bien (Parte 1/2)”

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *