En el artículo anterior analizamos el principio de responsabilidad única. En este segundo artículo abarcaremos la "O" de Open-closed principle ¡vamos!
Historia
Se considera que Bertrand Meyer fue quien utilizó por primera vez la expresión principio abierto-cerrado en su obra Object-Oriented Software Construction en 1988. En la época en que Meyer escribió esto, añadir campos o funciones a una librería implicaba, inevitablemente, modificar todos los programas clientes de esa librería. En vista del trabajo y las complicaciones que esto acarreaba, Meyer propuso este principio como una posible solución.
OCP: Principio Abierto-Cerrado
Entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para su extensión, pero cerradas para su modificación.
Descripción
Los módulos que cumplen con el principio abierto-cerrado tienen dos características principales. Estos son
- “Abiertos para la extensión”
Esto significa que el comportamiento del módulo puede ser extendido. Cuando los requerimientos de la aplicación cambian, debemos ser capaces de extender el módulo con estos nuevos comportamientos que satisfagan esos cambios. En otras palabras, debemos ser capaces de cambiar lo que el módulo hace.
2. “Cerrado para la modificación”
Esto significa que extender el comportamiento de un módulo no debería tener como resultado cambiar el código fuente, es decir, el código original debe permanecer sin cambios.
A simple vista da la impresión de que ambas características se contradicen. El camino normal para extender el comportamiento de una clase es cambiando su código fuente. ¿Cómo es posible que el comportamiento de una clase pueda ser modificado sin cambiar su código original? ¿cómo podemos cambiar lo que la clase hace, sin cambiarla?
La Abstracción es la clave
En Java o cualquier otro lenguaje orientado a objetos es posible crear abstracciones que sean fijas y, aun así, representen un grupo ilimitado de posibles comportamientos. Estas abstracciones son clases base, y el grupo ilimitado de posibles comportamientos será representado por todas las clases derivadas de esta clase base.
Es posible para una clase manipular una abstracción. Dicha clase entonces estará cerrada para su modificación ya que depende de una abstracción que es fija. Y además el comportamiento puede ser extendido creando nuevas clases derivadas de la abstracción.
Antes de que escribamos código que cumpla con el principio abierto-cerrado, veamos las consecuencias que nos puede traer violar este principio.
Dibujador de los Simpsons
Imaginemos que tenemos que desarrollar una aplicación para dibujar Simpsons. En un principio solo necesitamos dibujar a Homero.
Ahora imaginemos un nuevo requerimiento. Tenemos que dibujar a toda la familia Simpson.
Ya nuestro DibujadorSimpsons nos da señales de que algo que no está bien, sin embargo, aún es manejable.
Imaginemos un último requerimiento, esta vez necesitamos agregar a nuestro DibujadorSimpsons nada más y nada menos que a ¡TODO SPRINGFIELD!
¡Te deseo la mejor de las suertes con eso!
Ante esta complejidad podemos hacer uso de el principio abierto-cerrado.
Al agregar la abstracción Caricatura, nuestra clase DibujadorSimpsons cumple con el principio abierto-cerrado. Está cerrada para su modificación ya que tenemos la abstracción fija Caricatura. Además, se encuentra abierta para su extensión ya que al momento de querer agregar un nuevo personaje podemos derivar la clase correspondiente al personaje de Caricatura, sin la necesidad de cambiar el código original de DibujadorSimpsons.
De este modo nuestra clase DibujadorSimpsons nos queda:
Conclusión
De algún modo este principio es el corazón del diseño orientado a objetos. Aplicándolo correctamente podremos obtener los mayores beneficios de las tecnologías orientadas a objetos (por ejemplo, flexibilidad, reusabilidad, mantenibilidad). No es buena idea aplicar abstracción a cada parte de nuestra aplicación, de ser así terminaremos agregando complejidad innecesaria. Requiere dedicación por parte de nosotros los desarrolladores aplicar abstracción solo a esas partes del programa que están cambiando frecuentemente. Resistirnos a la abstracción prematura es tan importante como la propia abstracción.
Referencias
Robert C. Martin, (25 de octubre de 2002), Agile Software Development, Principles, Patterns and Practices, Upper Saddle River, New Jersey, Pearson Education, Inc.
Daniel, R. [markapsolon]. (2015, Agosto 11). Principios S.O.L.I.D - Open/Close - Daniel Rodríguez [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=4MaakYg5qis