Як я вже це пояснював, принцип відкритого / закритого типу визначає, що колись написаний код не слід змінювати (окрім виправлень помилок). Але якщо зміни моїх правил бізнесу не слід змінювати код, що впроваджує ці зміни? Я підозрюю, що я щось не розумію, як цей принцип, тому що він не має для мене сенсу.
Відповіді:
Це, мабуть, найскладніший із твердих принципів для пояснення. Дозвольте мені спробувати. Уявіть, що ви написали рахунок-фактура, який прекрасно працює і не має помилок. Це робить PDF-рахунок-фактуру.
Потім хтось каже, що хоче отримати рахунок-фактуру HTML із посиланнями в ньому. Ви не змінюєте жодного коду в Рахунку-фактурі, щоб задовольнити цей запит. Натомість ви складаєте інший клас, HTMLInvoice, який робить те, що вони зараз хочуть. Ви використовуєте спадщину, щоб не потрібно писати багато повторюваних кодів у HTMLInvoice.
Старий код, який використовував старий рахунок-фактура, не порушений або по-справжньому впливає. Новий код може використовувати HTMLInvoice. (Якщо ви також робите Ліскову заміну , L твердого, ви можете надати екземпляри HTMLInvoice існуючому коду, який очікує екземплярів рахунків.) Усі живуть щасливо.
Рахунок-фактура закритий для модифікації, відкритий для розширення. І ви повинні заздалегідь написати рахунок-фактуру належним чином, щоб це працювало, btw.
Ви читали статтю «Відкритий принцип » друзів дядька Боба в ObjectMentor? Я думаю, що це одне з кращих пояснень.
Є багато евристики, пов'язаної з об'єктно-орієнтованим дизайном. Наприклад, "всі змінні члена повинні бути приватними", або "глобальні змінні слід уникати", або "використання ідентифікації типу часу виконання (RTTI) небезпечно". Яке джерело цих евристик? Що робить їх справжніми? Чи завжди вони правдиві? У цій колонці досліджено принцип проектування, що лежить в основі цієї евристики - принципу відкритого закритого типу.
Як сказав Івар Якобсон: «Всі системи змінюються протягом свого життєвого циклу. Це потрібно мати на увазі, коли розробляються системи, які, як очікується, триватимуть довше, ніж перша версія. »Як ми можемо створити конструкції, стабільні в умовах змін, які триватимуть довше, ніж перша версія? Бертран Мейєр дав нам рекомендації ще в 1988 році, коли він придумав відомий тепер відкритий принцип. Перефразовуючи його:
ПРОГРАМНІ ЗАБЕЗПЕЧЕННЯ (КЛАСИ, МОДУЛИ, ФУНКЦІЇ, ETC.) ПОВИННІ ВІДКРИТИ ДЛЯ РОЗШИРЕННЯ, АЛЕ ЗАКРІТЛЕНО НА МОДИФІКАЦІЮ.
Коли одна зміна програми призводить до каскаду змін залежних модулів, ця програма виявляє небажані атрибути, які ми стали асоціювати з «поганим» дизайном. Програма стає крихкою, жорсткою, непередбачуваною та невиправданою. Принцип відкритого закриття атакує це дуже прямолінійно. У ньому йдеться про те, що ви повинні проектувати модулі, які ніколи не змінюються . Коли вимоги змінюються, ви розширюєте поведінку таких модулів, додаючи новий код, а не змінюючи старий код, який вже працює.
Опис
Модулі, які відповідають принципу відкритого закритого типу, мають два основні ознаки.
- Вони "Відкриті для розширення".
Це означає, що поведінку модуля можна продовжити. Що ми можемо змусити модуль вести себе по-новому і по-різному, коли змінюються вимоги програми або задовольняють потреби нових програм.- Вони закриті для внесення змін.
Вихідний код такого модуля є непорушним. Ніхто не може вносити зміни до вихідного коду.Здавалося б, ці два атрибути суперечать один одному. Нормальним способом розширення поведінки модуля є внесення змін до цього модуля. Як правило, вважається, що модуль, який неможливо змінити, має фіксовану поведінку. Як можна вирішити ці два протилежні атрибути?
Абстракція - це ключ ...
Відповідь Кейт Грегорі дуже добре, але розглянемо іншу ситуацію , коли нова вимога може бути задоволена порівняно невелика зміна в існуючому Invoiceкласі. Наприклад, скажімо, що нове поле має бути додане в PDF-рахунок-фактура. Згідно з OCP, нам все ж слід створити новий підклас, навіть якщо нове поле можна було б додати в існуючу реалізацію, змінивши кілька рядків коду.
На моє розуміння, OCP відображає реальність 80-х та початку 90-х, де проекти часто навіть не використовували контроль версій, а тим більше мали автоматизовані тести регресії або користь від складних інструментів рефакторингу. OCP була спробою уникнути ризику порушення коду, який був випробуваний вручну та введений у виробництво. Сьогодні у нас є кращі способи управління ризиком зламати робоче програмне забезпечення (а саме системи управління версіями, TDD та автоматизовані тестування та інструменти рефакторингу).
Особисто я вважаю, що цей принцип слід сприймати з дрібкою солі. Код органічний, бізнес змінюється і змінюється код відповідно до потреб бізнесу з часом.
Мені дуже важко обійтися з приводу того, що абстракція є ключовою. Що робити, якщо абстракція спочатку була неправильною? Що робити, якщо функція бізнесу суттєво змінилася?
Цей принцип по суті забезпечує те, що ОРИГІНАЛЬНІ наміри та поведінка дизайну ніколи не повинні змінюватися. Це, мабуть, працює для тих, хто має публічний API, і їхні клієнти мають труднощі в ногу з новими випусками та деякими іншими кращими справами. Однак якщо компанія володіє ВСЕМ кодом, я оскаржую цей принцип.
Маючи гарне тестове покриття вашого коду, це повинно зробити рефакторинг коду базою. Це означає, що добре помилитися з матеріалами - ваші тести допоможуть надати вам кращий дизайн.
Скажіть, що якщо немає ніяких тестів, то цей принцип є надійним.