[S.O.L.I.D.] Open-Closed Principle / Principio Abierto-Cerrado

2
12771

Open-Closed Principle / Principio Abierto-Cerrado

0. Índice de contenidos.

1. Introducción

Este es el segundo tutorial de la batería de tutoriales S.O.L.I.D.
El principio Abierto-Cerrado es probablemente el más fácil de aplicar de los 5.
Bertrand Meyer es el responsable de acuñar el término open/closed principle en su libro “Object Oriented Software Construction” de 1988 aunque fue popularizado junto con los otros principios del acrónimo SOLID por Martin Fowler una década más tarde.

2. Open-Closed Principle / Principio Abierto-Cerrado

La definición de OCP es:
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
La idea de este principio es que las clases están abiertas a la extensión pero cerradas a la modificación, lo que significa que ante peticiones de cambio en nuestro programa, hay que ser capaces de añadir funcionalidad sin modificar la existente (siempre que sea posible).

Por lo general, en un mal diseño, modificar una funcionalidad durante el ciclo de vida, suele conllevar una cadena de cambios en módulos dependientes, y este efecto puede propagarse en cascada si el código está muy acoplado.

La forma más común de seguir el principio OCP es usar interfaces o clases abstractas de las que dependen implementaciones concretas.
De esta forma puede cambiarse la implementación de la clase concreta manteniéndose la interfaz intacta.

3. Ejemplo

Tenemos una empresa que desde sus comienzos ha estado vendiendo agua embotellada,
y su programa informático tenía esta forma.

Ahora ha surgido una oportunidad de negocio y quiere empezar a vender botellas de té helado, por lo que necesita un cambio en su modelo.

Una primera aproximación sería algo similar a esto:

Pero implicaría realizar cambios en la empresa, que tiene que aprender a comunicarse con el nuevo tipo de botella, que probablemente sea muy parecida a la anterior.

Si hubieran seguido el principio Abierto-Cerrado su diagrama de clases habrían utilizado una interfaz que comunicaría el resto del sistema con las botellas, por lo que si no se cambia el api, el resto del sistema puede trabajar ajeno al cambio.
Quedaría de esta forma.

4. Conclusiones

Seguir este principio ayuda a que nuestros sistemas sean más mantenibles en el tiempo y soporten mejor los cambios, aunque ante todo hay que usar el sentido común. Un uso excesivo de interfaces reducirá la productividad y la legibilidad del código.
Espero que a los que no conocierais este principio os haya parecido interesante este concepto y os ayude a mejorar vuestra forma de programar.

5. Principio S.O.L.I.D.

2 Comentarios

Dejar respuesta

Please enter your comment!
Please enter your name here