Це порушення відкритого закритого принципу для оновлення константи, що представляє цінність у реальному світі?

У мене клас обчислення чистого річного доходу працівників. Він має константу, що представляє відсоток податку. Але одного дня ставка податку змінилася, тому мені потрібно виправити код.

Чи вказує акт фіксації цієї константи про порушення принципу відкритого закриття, оскільки він постулює, що клас повинен бути закритий для модифікації?

OCP можна краще зрозуміти, коли мислять про класи або компоненти, надані постачальником A в якійсь бібліотеці чорних скриньок, для використання користувачами B, C і D (зауважте, це просто ментальна модель, яку я використовую для наочності, не має значення, чи насправді єдиним користувачем класу є сам A).

Якщо B, C і D можуть використовувати або повторно використовувати надані класи для різних випадків використання, не потребуючи модифікації вихідного коду бібліотеки, то компонент відповідає OCP ( стосовно категорії випадків використання ). Існують різні засоби для досягнення цього, наприклад

• зробити клас успадковим (як правило, у поєднанні з шаблоном шаблону або шаблоном стратегії)

• шляхом надання "точок введення" для ін'єкції залежності

• шляхом надання параметрів конфігурації для класу або компонента (наприклад, за допомогою параметра конструктора "відсоток податку", як у вашому випадку, або за допомогою іншого механізму конфігурації)

• можливо, іншими засобами, залежно від мови програмування чи екосистеми

Типові приклади, які ви знайдете в текстових книгах, часто бувають першого або другого типу (я думаю, тому що в очах авторів цих книг третій тип занадто тривіальний, щоб його варто згадати).

Як бачите, це не має нічого спільного з забороною будь-якої зміни вихідного коду від постачальника A (як, наприклад, виправлення помилок, оптимізація або додавання нових функцій у зворотно сумісний спосіб), що є абсолютно не пов'язаним з OCP. OCP полягає в тому, як A проектує інтерфейс і деталізацію компонентів в лібі, тому різні сценарії повторного використання (наприклад, перенастроювання з різними ставками оподаткування) автоматично не викликають вимог до змін.

Тож незважаючи на те, що вам тут говорять інші, відповідь однозначно «так» , це було б порушенням OCP.

EDIT: схоже, що між ними хтось написав докладну публікацію в блозі про цю тему. Хоча його частини можна було б краще сказати (як зазначав Дерек Елкінс), схоже, автор взагалі поділяє мою точку зору, що "виконання OCP" - це не абсолютна властивість, а щось, що може бути оцінено лише у певному контексті категорії змін вимог.

Як кажуть інші, в ідеалі клас доходів робітників дозволяв би параметризувати постійну, роблячи цей клас незалежним від цього значення.

Зрештою, викликає додаток може також допускати параметризацію з точки зору зовнішньої конфігурації (наприклад, файл). Щойно у нас є зовнішня конфігурація, ми можемо змінити ставку податку - хоча врахуємо, що якщо файл конфігурації читається лише один раз при запуску, тоді додаток доведеться перезапустити для оновлених відсотків податків, щоб набути чинності, щоб це було чим слід тримати розум. Ми можемо надати функцію програми, щоб перечитати конфігурацію, коли вам це дозволено, або ми можемо надати більш складний механізм, який помічає, коли файл конфігурації змінюється ...

В довгостроковій перспективі ви можете виявити, що податкові питання вимагають більше, ніж лише відсоток - наприклад, що одного дня податкове законодавство є складнішим і вимагає декількох відсотків і деяких констант (наприклад, сума в розмірі до 10 тис. Доларів США, оподатковується на X%, тоді як решта оподатковується у Y%).

Це, головним чином, пропонує використовувати схему стратегії, де головний клас, про який йдеться, приймає об'єкт стратегії для обчислення податку.

Різні стратегії (і% -і та $ -константи) мають бути обрані з конфігураційного файлу, і тепер для додавання нової стратегії потрібно додати якийсь новий код, але не обов'язково оновити існуючий код.

Кожна стратегія може знати, як аналізувати / інтерпретувати власні аргументи зовнішньої конфігурації, а також як обчислювати фактичний податок.

Динамічно податок може додатково залежати від місцевого управління, тому у вас може бути місце, пов’язане із заробітком або зі співробітниками (або обома). У зовнішній конфігурації ми можемо пов'язувати місцевість із податковою стратегією.

Також дивіться ін'єкцію залежності , де ми керуємо цими речами чітко.

Якщо вам потрібно змінити клас, щоб змінити вартість податку, то його дизайн дійсно порушує OCP. Відповідна конструкція для того, що ви описали до цього, полягає в тому, щоб клас калькулятора взяв значення податку як параметр.

Якщо ваш клас інстальовано (це означає, що це не статичний клас), зробивши властивість класу змінних податків, значення якого вводиться через конструктор, ви також покращили б згуртованість класу.

Коротше кажучи, ваш сучасний дизайн робить ваш клас залежним від постійного значення, яке насправді не є постійним (визначаючи константу як величину, яка ніколи не зміниться незалежно від того, як, наприклад, значення PI). Це порушує OCP. Змініть дизайн, щоб отримати вартість податку як аргумент конструктора.

Цілком погоджуюся з @Becuzz, і я просто хочу підсумувати це: OCP - це пошук повторно використаних (отже, корисних) абстракцій, які вводяться в клас. Тож поведінка класу змінюється не шляхом зміни його коду, а шляхом надання йому різних реалізацій. Це чітко зрозуміло в книзі Роберта Мартіна " Agile Development Software, Principles, Patterns and Practices ", перевірте відповідний розділ "Принцип відкритого закриття", "Абстракція - ключ". З'ясовується ще одне хибне уявлення про те, що поведінку можна змінювати лише у спадок. Саме Бертран Мейєр запропонував у 1988 році у своїй книзі " Об'єктно-орієнтована побудова програмного забезпечення ", а не Роберт Мартін.

Як я бачу, це не є порушенням принципу відкритого закритого типу. Тим не менш, той факт, що щось, що може змінитись у часі (наприклад, відсоток податку), є постійною вадою дизайну: ви не повинні змінювати значення константи, а як обробляти відсоток податку. Це має бути якийсь тип налаштувань, який можна змінити без перекомпіляції всієї речі.