La respuesta de
Doc Brown es la más cercana a la precisa, las otras respuestas ilustran malentendidos del Principio Abierto Abierto.
Para articular explícitamente el malentendido, parece haber una creencia de que el OCP significa que no debes hacer cambios incompatibles hacia atrás (o incluso cualquier cambios o algo parecido). El OCP trata sobre diseñar componentes para que no necesite realizar cambios en ellos para ampliar su funcionalidad, independientemente de si esos cambios son compatibles con versiones anteriores o no. Hay muchas otras razones, además de agregar funcionalidad, por las que puede realizar cambios en un componente, ya sean compatibles con versiones anteriores (por ejemplo, refactorización u optimización) o incompatibles con versiones anteriores (por ejemplo, funcionalidad de eliminación y eliminación). El hecho de que pueda realizar estos cambios no significa que su componente haya violado el OCP (y definitivamente no significa que usted esté violando el OCP).
Realmente, no se trata en absoluto del código fuente. Una declaración más abstracta y relevante del OCP es: "un componente debe permitir la extensión sin necesidad de violar sus límites de abstracción". Iría más allá y diría que una versión más moderna es: "un componente debería hacer cumplir sus límites de abstracción pero permitir la extensión". Incluso en el artículo sobre el OCP de Bob Martin mientras él "describe" "cerrado a la modificación" como "el código fuente es inviolable", más tarde comienza a hablar sobre la encapsulación que no tiene nada que ver con modificar el código fuente y todo lo relacionado con la abstracción. límites.
Entonces, la premisa errónea en la pregunta es que el OCP es (destinado como) una guía sobre las evoluciones de una base de código. El OCP se suele consignar como "un componente debe estar abierto a las extensiones y cerrado a las modificaciones de los consumidores". Básicamente, si un consumidor de un componente desea agregar la funcionalidad al componente, debería poder extender el componente antiguo a uno nuevo con la funcionalidad adicional, pero debería no poder cambiar el componente antiguo.
El OCP no dice nada sobre el creador de un componente cambiando o eliminando . El OCP no aboga por mantener compatibilidad de errores para siempre. Usted, como creador, no está violando el OCP al cambiar o incluso eliminar un componente. Usted, o más bien los componentes que ha escrito, está violando el OCP si la única forma en que los consumidores pueden agregar funcionalidad a sus componentes es mediante la mutación, por ejemplo. por parches de mono o tener acceso al código fuente y recompilar. En muchos casos, ninguna de estas opciones es para el consumidor, lo que significa que si su componente no está "abierto para extensión" no tiene suerte. Simplemente no pueden usar su componente para sus necesidades. El OCP argumenta no colocar a los consumidores de su biblioteca en esta posición, al menos con respecto a alguna clase de "extensiones" identificable. Incluso cuando se pueden realizar modificaciones en el código fuente o incluso en la copia principal del código fuente, es mejor "simular" que no se puede modificar ya que existen muchas consecuencias negativas potenciales al hacerlo. .
Entonces, para responder a sus preguntas: No, estas no son violaciones del OCP. Ningún cambio que haga un autor puede ser una violación del OCP porque el OCP no es una proporción de los cambios. Sin embargo, los cambios pueden crear violaciones del OCP y pueden estar motivados por fallas del OCP en versiones anteriores del código base. El OCP es una propiedad de un fragmento de código en particular, no la historia evolutiva de un código base.
Para el contraste, la compatibilidad con versiones anteriores es una propiedad de un cambio de código. No tiene sentido decir que una parte del código es o no es compatible con versiones anteriores. Solo tiene sentido hablar de la compatibilidad con versiones anteriores de algunos códigos con respecto a algunos códigos más antiguos. Por lo tanto, nunca tiene sentido hablar de que el primer corte de un código sea compatible con versiones anteriores o no. El primer corte de código puede satisfacer o no satisfacer el OCP, y en general podemos determinar si algún código satisface al OCP sin hacer referencia a ninguna versión histórica del código.
En lo que respecta a su última pregunta, podría decirse que es un tema ajeno a StackExchange en general debido a que se basa principalmente en la opinión, pero por lo general es bienvenido a la tecnología y especialmente a JavaScript, donde en los últimos años se ha llamado al fenómeno que usted describe fatiga de JavaScript . (No dude en google para encontrar una variedad de otros artículos, algunos satíricos, que hablan de esto desde múltiples perspectivas.)