Ответ Дока Брауна является наиболее точным, остальные ответы иллюстрируют недопонимание открытого закрытого принципа.
Чтобы явно сформулировать недоразумение, кажется , есть мнение , что OCP означает , что вы не должны делать назад несовместимые изменения (или даже какие - либо изменения или что - то вдоль этих линий.) ОСР о проектировании компонентов , так что вам не нужно , чтобы внесите в них изменения, чтобы расширить их функциональность, независимо от того, являются ли эти изменения обратно совместимыми или нет. Помимо добавления функциональных возможностей, существует множество других причин, по которым вы можете вносить изменения в компонент независимо от того, являются ли они обратно совместимыми (например, рефакторинг или оптимизация) или обратно несовместимыми (например, не рекомендуется использовать или удалять функциональность). То, что вы можете внести эти изменения, не означает, что ваш компонент нарушил OCP (и определенно не означает, что вы нарушают OCP).
На самом деле, это вовсе не исходный код. Более абстрактное и актуальное утверждение OCP: «компонент должен допускать расширение без необходимости нарушать границы абстракции». Я бы пошел дальше и сказал бы, что более современное представление: «компонент должен обеспечивать свои границы абстракции, но допускает расширение». Даже в статье об OCP Боба Мартина, когда он «описывает» «закрытый для модификации» как «исходный код нерушим», он позже начинает говорить об инкапсуляции, которая не имеет ничего общего с модификацией исходного кода и всем, что связано с абстракцией границы.
Таким образом, ошибочная предпосылка в этом вопросе заключается в том, что OCP - это (задумано как) руководство по развитию кодовой базы. У OCP обычно лозунг: «компонент должен быть открыт для расширений и закрыт для изменений потребителями». По сути, если потребитель компонента хочет добавить функциональность к компоненту, он должен иметь возможность расширить старый компонент на новый с дополнительными функциями, но он не должен иметь возможность изменять старый компонент.
OCP ничего не говорит о том, что создатель компонента изменил или удалил функциональность. OCP не поддерживает вечную совместимость с ошибками . Вы, как создатель, не нарушаете OCP, изменяя или даже удаляя компонент. Вы, или, вернее, написанные вами компоненты, нарушаете OCP, если единственный способ, которым потребители могут добавить функциональность к вашим компонентам, - это изменить его, например, с помощью патчей для обезьян.или иметь доступ к исходному коду и перекомпилировать. Во многих случаях ни один из этих вариантов для потребителя не означает, что если ваш компонент не «открыт для расширения», им не повезло. Они просто не могут использовать ваш компонент для своих нужд. OCP утверждает, что не ставит потребителей вашей библиотеки в это положение, по крайней мере, в отношении некоторого идентифицируемого класса «расширений». Даже когда могут быть внесены изменения в исходный код или даже в первичную копию исходного кода, лучше всего «притворяться», что вы не можете его изменить, поскольку это может привести к многочисленным негативным последствиям.
Итак, чтобы ответить на ваши вопросы: Нет, это не нарушения OCP. Никакие изменения, вносимые автором, не могут быть нарушением OCP, поскольку OCP не является прототипом изменений. Изменения, однако, могут создавать нарушения OCP, и они могут быть мотивированы сбоями OCP в предыдущих версиях кодовой базы. OCP - это свойство определенного куска кода, а не эволюционная история кодовой базы.
Напротив, обратная совместимость является свойством изменения кода. Нет смысла говорить, что какой-то кусок кода обратно совместим. Имеет смысл говорить о обратной совместимости некоторого кода по отношению к более старому коду. Следовательно, никогда не имеет смысла говорить о том, что первый фрагмент некоторого кода обратно совместим или нет. Первый фрагмент кода может удовлетворять или не удовлетворять OCP, и в целом мы можем определить, удовлетворяет ли какой-то код OCP, не обращаясь к каким-либо историческим версиям кода.
Что касается вашего последнего вопроса, то он, возможно, не является темой для StackExchange в целом, поскольку он в первую очередь основан на мнениях, но если не считать его, можно приветствовать технологию и, в частности, JavaScript, где в последние несколько лет описываемое вами явление называлось усталостью JavaScript . (Не стесняйтесь в Google, чтобы найти множество других статей, некоторые сатирические, говорящие об этом с разных точек зрения.)