Aclarar el principio abierto / cerrado

Como ya he explicado, el principio abierto / cerrado establece que una vez que el código escrito no debe modificarse (aparte de las correcciones de errores). Pero si cambian las reglas de mi negocio, ¿no debería modificar el código que implementa esos cambios? Sospecho que no estoy entendiendo algo sobre cómo funciona el principio porque no tiene sentido para mí.

Este es probablemente el más sólido de los principios sólidos para explicar. Déjame intentarlo. Imagina que escribiste una clase de Factura que funciona perfectamente y no tiene errores. Hace un PDF de una factura.

Entonces alguien dice que quiere una factura HTML con enlaces. No cambia ningún código en Factura para satisfacer esta solicitud. En cambio, crea otra clase, HTMLInvoice, que hace lo que ahora quieren. Aprovecha la herencia para no tener que escribir mucho código duplicado en HTMLInvoice.

El código antiguo que usaba la antigua factura no está roto ni afectado de ninguna manera. El nuevo código puede usar HTMLInvoice. (Si también realiza la sustituibilidad de Liskov , la L de sólido, puede dar instancias HTMLInvoice al código existente que espera instancias de factura.) Todos viven felices para siempre.

La factura está cerrada a modificación, abierta a extensión. Y tiene que escribir la factura correctamente de antemano para que esto funcione, por cierto.

¿Has leído el artículo El principio abierto-cerrado de los amigos del tío Bob en ObjectMentor? Creo que es una de las mejores explicaciones por ahí.

Hay muchas heurísticas asociadas con el diseño orientado a objetos. Por ejemplo, "todas las variables miembro deben ser privadas", o "las variables globales deben evitarse", o "usar la identificación de tipo de tiempo de ejecución (RTTI) es peligroso". ¿Cuál es la fuente de estas heurísticas? ¿Qué los hace verdaderos? ¿Son siempre ciertas? Esta columna investiga el principio de diseño que subyace a estas heurísticas: el principio abierto-cerrado.

Como dijo Ivar Jacobson: “Todos los sistemas cambian durante sus ciclos de vida. Esto debe tenerse en cuenta al desarrollar sistemas que se espera que duren más que la primera versión ”. ¿Cómo podemos crear diseños que sean estables ante el cambio y que duren más que la primera versión? Bertrand Meyer nos dio orientación en 1988, cuando acuñó el ahora famoso principio abierto-cerrado. Parafraseándolo:

LAS ENTIDADES DE SOFTWARE (CLASES, MÓDULOS, FUNCIONES, ETC.) DEBEN ABRIRSE PARA SU EXTENSIÓN, PERO CERRARSE PARA MODIFICARSE.

Cuando un solo cambio en un programa resulta en una cascada de cambios en módulos dependientes, ese programa exhibe los atributos indeseables que hemos llegado a asociar con un diseño "malo". El programa se vuelve frágil, rígido, impredecible e irreutilizable. El principio abierto-cerrado ataca esto de una manera muy directa. Dice que debe diseñar módulos que nunca cambien . Cuando los requisitos cambian, amplía el comportamiento de dichos módulos agregando código nuevo, no cambiando el código antiguo que ya funciona.

Descripción

Los módulos que se ajustan al principio abierto-cerrado tienen dos atributos principales.

1. Están "abiertos para la extensión".
   Esto significa que el comportamiento del módulo puede extenderse. Que podemos hacer que el módulo se comporte de formas nuevas y diferentes a medida que cambian los requisitos de la aplicación, o para satisfacer las necesidades de las nuevas aplicaciones.
2. Están "cerrados por modificación".
   El código fuente de dicho módulo es inviolable. Nadie puede hacer cambios en el código fuente.

Parece que estos dos atributos están en desacuerdo entre sí. La forma normal de extender el comportamiento de un módulo es realizar cambios en ese módulo. Normalmente se cree que un módulo que no se puede cambiar tiene un comportamiento fijo. ¿Cómo se pueden resolver estos dos atributos opuestos?

La abstracción es la clave ...

La respuesta de Kate Gregory es muy buena, pero considere una situación diferente en la que un nuevo requisito puede satisfacerse con un cambio relativamente pequeño en la Invoiceclase existente . Por ejemplo, supongamos que se debe agregar un nuevo campo al PDF de la factura. Según OCP, aún deberíamos crear una nueva subclase, incluso si el nuevo campo pudiera agregarse en la implementación existente cambiando algunas líneas de código.

En mi opinión, OCP refleja la realidad de los años 80 y principios de los 90, donde los proyectos a menudo ni siquiera usaban el control de versiones, y mucho menos tenían pruebas de regresión automatizadas o el beneficio de sofisticadas herramientas de refactorización. OCP fue un intento de evitar el riesgo de romper el código que había sido probado manualmente y puesto en producción. Hoy, tenemos mejores formas de gestionar el riesgo de romper el software de trabajo (a saber, sistemas de control de versiones, TDD y pruebas automatizadas, y herramientas de refactorización).

Personalmente, creo que este principio debe tomarse con una pizca de sal. El código es orgánico, las empresas cambian y el código cambia según las necesidades de una empresa a medida que pasa el tiempo.

Me resulta muy difícil entender el hecho de que la abstracción es clave. ¿Qué pasa si la abstracción estaba originalmente equivocada? ¿Qué pasa si la función comercial ha cambiado significativamente?

Este principio esencialmente garantiza que las intenciones y el comportamiento ORIGINALES de un diseño nunca deben cambiar. Eso probablemente funcione para aquellos que tienen API públicas y sus clientes tienen problemas para mantenerse al día con las nuevas versiones y algunos otros casos extremos. Sin embargo, si una empresa posee TODO el código, entonces cuestiono este principio.

Tener una buena cobertura de prueba de su código debería facilitar la refactorización de su base de código. Significa que está bien equivocarse: sus pruebas ayudarán a guiarlo hacia un mejor diseño.

Dicho esto, si no hay pruebas, entonces este principio es sólido.