Principios SOLID: Principio abierto/cerrado
Hace varias semanas escribía sobre el Principio de Responsabilidad Única, primero de los principios SOLID. Hoy vamos a abordar e intentar entender bien que significa el segundo, el correspondiente a la letra ‘O’, The OCP: The Open-Closed Principle o Principio Abierto-Cerrado.
El principio
Se considera que Bertrand Meyer fue el primero en hacer referencia a este principio en su libro Object-Oriented Software Construction, de 1988. En él, lo define como:
Los módulos deben ser a la vez abiertos y cerrados.
Para Bertrand Meyer esto que puede parecer una contradicción, no lo es, ya que ambas afirmaciones corresponden a naturalezas diferentes. Un módulo es abierto si está disponible para expandir el conjunto de operaciones que realiza o añadir campos a sus estructuras de datos. Y, a la vez, estará cerrado si está disponible para ser utilizado por otros módulos.
Según Robert C. Martin, en su libro Software Agile Development, este principio se define como:
Las entidades de software (clases, módulos, funciones…etc), deberían ser abiertas para la extensión pero cerradas para la modificación.
Esta definición, que probablemente la hayamos escuchado o leído más veces que la de Meyer, ¿sabemos a qué se refiere?, ¿conocemos como debemos programar para cumplir con ella? ¿entendemos que significa eso de abierta a la extensión y cerrada a la modificación?
Descripción del principio abierto-cerrado
Los módulos que cumplen con el principio abierto-cerrado tienen dos características principales:
- Abiertos para la extensión
Esto significa que el comportamiento de un módulo puede ser extendido. Cuando los requerimientos de una aplicación cambien, debemos ser capaces de extender el módulo con nuevos comportamientos que satisfagan esos cambios, es decir, debemos ser capaces de cambiar lo que el módulo hace.
2. Cerrado para la modificación
Un módulo estará cerrado si dispone de una descripción (interface) estable y bien definida. Extender el comportamiento de un módulo no debería tener como resultado cambiar el código original del módulo, es decir, el código original del módulo debería permanecer intocable.
Nuevamente, parece que estas dos características anteriores podrían estar en desacuerdo entre sí ya que la forma más común de extender el comportamiento de un módulo es hacer cambios en el mismo, entonces:
¿cómo es posible que los comportamientos de un módulo sean modificados sin modificar el código existente? ¿cómo cambiamos un módulo..sin cambiar el módulo?
La solución es: Abstracción
Las abstracciones son clases bases abstractas que pueden tener ilimitados comportamientos representados por todas las clases que pueden ser derivadas de ellas.
Podríamos decir que un módulo estaría cerrado para la modificación si depende de una abstracción que es fija y no cambia, y, sin embargo, su comportamiento puede ser extendido creando nuevas clases derivadas de su abstracción.
Los patrones de diseño Strategy y Template, son las formas más comunes que satisfacen el principio abierto-cerrado ya que representan una separación muy clara entre la funcionalidad y los detalles de implementación de esa funcionalidad.
Complejidad innecesaria
Dice un refrán “Miénteme una vez y la culpa será tuya, miénteme dos veces y la culpa será mía”. Robert C. Martin cuenta que tener esta actitud en ocasiones puede ser beneficiosa para el desarrollo de software ya que nos ayuda a mantenernos alejados de complejidades innecesarias. La idea principal es que inicialmente escribiremos nuestro código sin esperar que cambie. Posteriormente, cuando un cambio ocurra, entonces implementaremos las abstracciones que nos protejan contra ese cambio y cambios futuros de tipos similares. Si optamos por esta estrategia, la de no abstraer a las primeras de cambio partes de nuestro código en las que no estemos seguro que vaya a cambiar, entonces deberíamos ser capaces de ‘adelantar’ todo lo posible en el tiempo los diferentes cambios en los que nos podríamos ver envueltos para así crear las abstracciones apropiadas, es decir, debemos estimular los cambios lo más tempranamente posible y no avanzar en nuestro código lo suficiente como para que incluir las abstracciones necesarias posteriormente sea complejo.
A la pregunta, ¿cómo estimulamos el cambio en nuestro desarrollo para así advertirlo cuánto antes?, pues aplicando técnicas de desarrollo ágil:
- Escribir los tests primero: El testing es una de las formas en las que ponemos en uso nuestro código. Escribiendo los tests primero forzamos al sistema a ser testeable y construiremos las abstracciones necesarias para que así sea.
- Desarrollar usando ciclos muy cortos en el tiempo: No esperar largos ciclos de semanas o meses que nos dificulten ver los cambios en la funcionalidad cuando ha pasado mucho tiempo.
- Mostrar el desarrollo a los stakeholders para que así nos puedan advertir de posibles modificaciones y además, poner en valor a usuarios y clientes lo más rápido posible para que nos puedan advertir cambios en la funcionalidad lo antes posible.
- Desarrollar las características más importantes en primer lugar
Y hasta aquí el segundo de los principios SOLID. En una próxima entrega nos acercaremos a entender el siguiente principio: Principio de sustitución de Liskov.
Como siempre, cualquier aclaración, corrección o propuesta de mejora será bienvenida.
Chimpún.
Bibliografía
Agile Software Development, Robert C. Martin.
Construcción de Software Orientado a Objetos, de Bertrand Meyer.
