BlogBlog de José Antonio Yáñez Jiménez

En esta ocasión trataremos el segundo de los principios SOLID. Este es, desde mi punto de vista, uno de los principios más difíciles de llevar a cabo a rajatabla en los entornos de producción, sobre todo en los que no se llevó una concienzuda planificación inicial.

Open Closed, las entidades de software deben ser abiertas para su extensión, pero cerradas para su modificación

Como sabemos, todo sistema cambia durante su ciclo de vida, el código que liberemos inicialmente se parecerá en poco o nada pasado un tiempo, por lo que debemos tratar de crear sistemas lo más estable posibles a los cambios que irán sufriendo.

Para ello debemos permitir que se puedan añadir nuevas entidades (clases, módulos, funciones, etc) a nuestra aplicación, pero sin tener que realizar cambios en la estructura que ya tenemos creada. Simplemente debemos aprovecharnos de la abstracción, el poliformismo, o la inyección de una dependencia.

El peligro de este principio en un ejemplo

En un ejemplo rápido, supongamos que queremos exportar un fichero de informes diario de los visitantes de nuestro sitio web. Inicialmente exportamos estos datos en JSON:

class Report
  def body
     # Aquí va el código que exporta nuestros datos sobre visitantes
  end

  def print
     body.to_json
  end
end

El problema viene cuando, por ejemplo, un consultor externo (o nosotros mismos) tenemos la necesidad de recibir esos datos en otro formato que no sea JSON, como por ejemplo XML, un feed, etc. Con el diseño actual, nos veríamos obligados a modificar la función print, añadiendo condiciones por ejemplo. Sin embargo, un planteamiento inicial tan simple como el siguiente habría solucionado el problema:

class Report
  def body
     # Aquí va el código que exporta nuestros datos sobre visitantes
  end

  def print(formatter: JSONFormatter.new)
    # Por defecto la exportación se realiza en JSON
    # Pero podemos modificar el comportamiento al invocar a la función
    formatter.format body
  end
end

Este, que es un ejemplo muy sencillo, puede resultar nimio. Precisamente esa es la clave de que el ejemplo escogido sea tan simple. El problema viene cuando en los entornos de producción hace falta introducir mejoras en el menor tiempo posible. En ese momento viene la tentación de hacer el cambio rápido añadiendo «parches» sobre un código existente. Esto ocurre una vez, y luego otra, y otra… Y de repente, un día te das cuenta de que necesitas la ayuda de un equipo de criptógrafos para descifrar lo que esas líneas de código que estás viendo se supone que hacen.

Más información

Open/Closed principle avanzado con ejemplos en Java

buenas prácticas, desarrollo, development, SOLID

By José Antonio Yáñez Jiménez  -        
Soy un Full Stack Developer que vive en Valladolid. Actualmente trabajo en la empresa Ilunion Tecnología y Accesibilidad. Soy un apasionado de la informática, la tecnología, aficionado a la fotografía y enamorado del diseño eficiente.

---

---