Principio de Abierto Cerrado

El principio Abierto/Cerrado hace parte del los principios SOLID y se considera a Bertrand Meyer como la persona que lo acuñó.

"Las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para su extensión, pero cerradas para su modificación"

Este principio busca no cambiar el código existente que funciona bien (Cerrado). ¿Pero si llegan nuevos requisitos? o ¿Si cambian los requisitos ya existentes?, ¿Qué hacer?, es ahí donde se debe poder extender el comportamiento de las entidades de software a través de la adición de nuevo código (Abierto).

Es claro entonces que para cumplir con este principio se debe:

• Estar Abierto para Extender

Con el pasar del tiempo, todo cambia, es inevitable que los requisitos de una aplicación no lo hagan, por eso cuando llega el momento, es conveniente poder cambiar el comportamiento y esto se logra a través de poder extender las entidades de software.

• Estar Cerrado para su Modificación

El código fuente de las entidades de software no debe modificarse, es decir, su código debe ser inmutable.

¿Cómo así que se debe cambiar el comportamiento, pero su código fuente no se debe cambiar?, ¿Esto cómo es posible?. Aunque todo esto parece confuso, contradictorio y hace que surjan muchas preguntas, en la programación orientada a objetos (POO) existe la herencia y como algunos lenguajes no permiten herencia múltiples, también existe la posibilidad de implementar interfaces o clases abstractas, con esto se puede extender las entidades de software, sin modificar el código fuente del padre (objeto de quien se hereda).

Con base en lo anterior ¿Qué estrategia utilizar?, en este punto surge la abstracción como la piedra angular de este principio, pues las entidades de software pueden utilizar una clase abstracta cuyo comportamiento está cerrado (que no se puede modificar), pero si en un futuro se quiere cambiar su comportamiento puede extenderse creando entidades de software que desciendan de dicha clase abstracta. La abstracción se centra en el que hace más no en el cómo lo hace, aislando los comportamientos específicos de una entidad, dejando que un desarrollador pueda sobreescribir o implementar dicho comportamiento como él lo desee.

Este artículo es un abrebocas y un pequeño resumen para este principio. Te invito al plato fuerte, a que profundices aún más, para esto te propongo que leas el siguiente artículo y en tus comentarios me cuentes tus impresiones. ¡No te vas a arrepentir de leerlo!:
http://web.archive.org/web/20060822033314/http://www.objectmentor.com/resources/articles/ocp.pdf