SOLID – Principio Abierto/Cerrado
Este principio tiene como objetivo mantener en la cabeza del desarrollador que los módulos y todo el código que se escriba esté abierto a extender su funcionalidad en el futuro y evitar su modificación.
Por ejemplo, si tenemos una aplicación que imprima las nóminas de sus empleados, a la hora del desarrollo, debemos pensar en cómo diseñar el módulo del que depende la presentacion si algun día queremos que además se puedan imprimir en muchos y variados formatos.
La finalidad de este principio es aislar lo más posible al sistema de un cambio. Volviendo a la contabilidad: si tenemos un módulo que imprime los datos de las nóminas (ImprimirNomina) a partir de la peticion de un actor, este módulo no debe conocer la presentacion concreta final de los datos. ¡Si después quisiéramos cambiar la lógica de una presentacion tendríamos que cambiar el codigo fuente de la clase que imprime!
Una de las máximas de este principio es: mantén las partes críticas de tu aplicacion lo más aislada de los cambios posible, evitando que dependan de otras partes más volátiles y manteniendo la comunicacion mediante interfaces.
Si ahora quisiéramos presentar los datos en formato PDF además de Excel y Web, tendríamos que acudir a la clase nómina y cambiar el código fuente añadiendo un método para ello. Cosas tan nimias como un cambio en el nombre del método de cualquiera de las clases que presente los datos implicaría una necesaria refactorización en la clase Nómina. Por eso, es necesario depender de abstracciones, para mantener al sistema lo más aislado de los cambios posible a través de «contratos» o interfaces que aseguren que los cambios en la extension de un módulo no tendrán impacto en otros.
Ahora nuestro código está abierto a la extension, sin necesidad de modificar el código anterior! Hemos cumplido con el principio open-close.