Principio Abierto-Cerrado

Samuel Martín Gómez-Calcerrada

AUTENTIA.COM

Madrid, 04 de Agosto de 2014

Bertrand Meyer es el responsable de acuñar el término open/closed principle en su libro “Object Oriented Software Construction” - 1988

Martin Fowler ha sido el responsable de popularizarlo junto con el resto de principios S.O.L.I.D (first five principles) en “Refactoring: Improving the Design of Existing Code” - 1999

Principio Abierto-Cerrado(Open-Closed-Principle)

Acrónimo introducido por Michael Feathers

S: Single Responsibility Principle (SRP) - Principio de responsabilidad únicaO: Open-Closed Principle (OCP) - Principio Abierto CerradoL: Liskov Substitution Principle(LSP) - Principio de sustitución de LiskovI: Interface Segregation Principle(ISP) - Principio de segregación de la interfazD: Dependency Inversion Principle(DIP) - Principio de Inversión de la dependencia

S.O.L.I.D - ¿Cuáles son?

Principio Abierto-Cerrado (Open-Closed-Principle)

Definición:Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Principio Abierto-Cerrado(Open-Closed-Principle)

En un mal diseño, cuando se modifica una funcionalidad durante el ciclo de vida, suele conllevar una cadena de cambios en módulos dependientes unos de otros.

Fuente: http://appraisaltodayblog.files.wordpress.com/2013/01/stress-hitting-head-on-keyboard.jpg?w=400&h=267

OCP - Introducción

Para evitar esto, debemos usar el principio OC.

Las clases deben ser capaces de extenderse sin modificar su contenido.

OCP - Introducción

¿Cómo se consigue esto?

La forma más común es a través de interfaces o clases abstractas de las que depende una implementación concreta.

Cuando cambie la funcionalidad la interfaz se mantiene y sólo cambia la implementación.

OCP - Introducción

Nuestra empresa se ha dedicado desde sus inicios a vender agua embotellada

Ahora se plantea vender botellas de NesTea

Fuente: http://2.bp.blogspot.com/_DIPF2NH_r-w/TEzHMqABkhI/AAAAAAAAAlc/qRzfe7-mTuE/s1600/water_bottles_caps.jpg

Ejemplo - Mal diseño

OCP Mal diseño - Original

OCP Mal diseño - Añadiendo funcionalidad

OCP Buen diseño - Uso de herencia

En caso de estar ante una modificación demasiado drástica normalmente tendremos que modificar la interfaz o agregar otra, como en el caso de que la empresa empiece a comercializar latas de aluminio.

Pero esto deben ser casos excepcionales.

Fuente: http://s01.s3c.es/imag/_v0/640x419/6/8/0/latas.jpg

OCP - Caso extremo

Seguir este principio ayudará a que nuestros sistemas sean más mantenibles en el tiempo y soporten mejor los cambios.

Seguir este principio demasiado a rajatabla puede ser perjudicial para el proyecto, ya que el abuso de interfaces reducirá la productividad y la legibilidad. Debemos usar el sentido común en base a nuestro conocimiento del proyecto.

OCP - Conclusiones

Fuente:

http://blog.themsls.org/wp-content/uploads/2014/04/Shutterstock_Questions_Image.jpg

¿Preguntas?