Відповідь Дока Брауна найближча до точної, інші відповіді ілюструють непорозуміння відкритого закритого принципу.
Щоб чітко сформулювати непорозуміння, мабуть, існує думка, що OCP означає, що вам не слід вносити назад несумісні зміни (або навіть якісь зміни чи щось у цьому напрямку.) OCP полягає в розробці компонентів, щоб вам не потрібно було вносити зміни до них, щоб розширити їх функціональність, незалежно від того, сумісні вони назад чи ні. Окрім додавання функціональності, існує багато інших причин, завдяки яким ви можете внести зміни до компонента, незалежно від того, чи вони сумісні назад (наприклад, рефакторинг чи оптимізація) або назад несумісні (наприклад, знецінення та видалення функціональності). Те, що ви можете внести ці зміни, не означає, що ваш компонент порушив OCP (і, безумовно, не означає, що ви порушують OCP).
Дійсно, справа зовсім не у вихідному коді. Більш абстрактним і релевантним твердженням OCP є: "компонент повинен допускати розширення, не порушуючи його меж абстракції". Я б хотів піти далі і сказати, що більш сучасним виданням є: "компонент повинен виконувати свої межі абстракції, але допускати розширення". Навіть у статті про OCP Боб Мартін, поки він "описує" "закритий до модифікації" як "вихідний код є непорушним", він пізніше починає говорити про інкапсуляцію, яка не має нічого спільного з зміною вихідного коду, і все, що стосується абстракції. межі.
Отже, несправна передумова у питанні полягає в тому, що OCP є (призначеним як) керівництвом щодо еволюції кодової бази. OCP, як правило, впорядковується як "компонент повинен бути відкритим для розширень та закритим для модифікації споживачами". В основному, якщо споживач компонента хоче додати функціональність до компонента, він повинен мати можливість розширити старий компонент на новий з додатковим функціоналом, але він не повинен мати змогу змінити старий компонент.
OCP нічого не говорить про те, що творець компонента змінює або видаляє функціонал. OCP не виступає за збереження сумісності помилок назавжди. Ви, як творець, не порушуєте OCP, змінюючи або навіть видаляючи компонент. Ви, а точніше написані вами компоненти, порушуєте OCP, якщо єдиний спосіб, коли споживачі можуть додати функціональність до ваших компонентів, - це його мутація, наприклад, виправлення мавп.або мати доступ до вихідного коду та перекомпілювати. У багатьох випадках жоден з цих варіантів для споживача не означає, що якщо ваш компонент не "відкритий для розширення", їм не пощастило. Вони просто не можуть використовувати ваш компонент для своїх потреб. OCP стверджує, що не ставити споживачів вашої бібліотеки в цю позицію, принаймні, стосовно якогось ідентифікованого класу "розширень". Навіть коли можна змінити вихідний код або навіть первинну копію вихідного коду, краще "зробити вигляд", що ви не можете його змінити, оскільки для цього є багато можливих негативних наслідків.
Отже, щоб відповісти на ваші запитання: Ні, це не порушення OCP. Жодна зміна, яку автор вносить, не може бути порушенням OCP, оскільки OCP не є змістом. Зміни, однак, можуть створювати порушення OCP, і вони можуть бути мотивовані відмовами OCP у попередніх версіях бази даних коду. OCP - це властивість певного фрагмента коду, а не еволюційна історія бази даних.
На противагу цьому, зворотна сумісність є властивістю зміни коду. Немає сенсу говорити, що якийсь фрагмент коду сумісний або не підтримується назад. Має сенс лише говорити про зворотну сумісність якогось коду стосовно якогось старшого коду. Тому ніколи не має сенсу говорити про те, що перший відрізок якогось коду є сумісним назад чи ні. Перший розріз коду може задовольнити або не задовольнити OCP, і загалом ми можемо визначити, чи задовольняє якийсь код OCP, не посилаючись на будь-які історичні версії коду.
Що стосується вашого останнього запитання, то це, можливо, поза темою для StackExchange, як правило, засноване на думці, але недолік цього вітається в техніці, особливо в JavaScript, де за останні кілька років явище, яке ви описуєте, називалося JavaScript втомою . (Не соромтеся гугл, щоб знайти різноманітні інші статті, якісь сатиричні, говорячи про це з різних точок зору.)