Принцип інверсії залежностей

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

Принцип інве́рсії зале́жностей (англ. Dependency Inversion Principle, DIP) — один з п'яти SOLID-принципів об'єктно-орієнтованого проектування програм, суть якого полягає у розриві зв'язності між програмними модулями вищого та нижчого рівнів за допомогою спільних абстракцій.

Принцип формулюється наступним чином:

  • Модулі вищого рівня не повинні залежати від модулів нижчого рівня. Обидва типи модулів повинні залежати від абстракцій.
  • Абстракції не повинні залежати від деталей реалізації. Деталі реалізації повинні залежати від абстракцій.

Принцип інверсії залежностей вирішує проблеми невдалого проектування програм.

Залежність від абстракцій[ред.ред. код]

Щоб уникнути іншої залежності, крім залежності від абстракцій, потрібно:

Проблеми невдалого проектування програм[ред.ред. код]

Роберт Мартін у своїй статті The Dependency Inversion Principle[1] навів критерії, за якими, на його думку, можна визначити невдало спроектовану програму.

Програма, або її частина, яка виконує своє призначення і в той самий час має одну або декілька наступних особливостей, є невдало спроектованою:

  1. У програму, або її частину, складно внести зміни, оскільки будь-яка зміна впливає на занадто велику кількість компонентів системи (жорсткість).
  2. При внесенні змін порушується робота компонентів системи у несподіваних місцях (крихкість).
  3. Складно використати той самий код у іншій програмі, оскільки його неможливо витягти з даної програми (непорушність).

Програма спроектована жорстко, якщо у неї не можна легко внести зміни. Така жорсткість обумовлена тим фактом, що одна єдина зміна до тісно взаємозв'язаного коду дає початок послідовності змін в залежних модулях. Якщо дизайнери або розробники не здатні визначити межі тієї послідовності змін, вплив цих змін неможливо спрогнозувати. А отже і наслідки цих змін спрогнозувати неможливо. Керівники проектів, які стикаються з подібною непередбачуваністю, неохоче погоджуються на впровадження змін. Тому такий дизайн офіційно визнається жорстким.

Крихкість означає схильність програми до виникнення помилок у багатьох місцях після внесення хоча б однієї правки. Часто буває, що проблеми виникають у місцях, які не мають концептуального відношення до місця, якого стосувалась правка. Така крихкість знижує довіру до організації, що займалася проектуванням та розробкою програми. Користувачі та керівники проектів не можуть передбачити якість їх продукту. Прості зміни, внесені до однієї частини програми, призводять до збоїв у роботі зовсім не пов'язаних з нею інших частин програми. Спроби виправити це призводять до виникнення ще більших труднощів, і процес підтримки продукту починає нагадувати собаку, що бігає за власним хвостом.

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

Історія[ред.ред. код]

Принцип інверсії залежностей був введений Робертом Мартіном і викладений ним у кількох публікаціях, таких як Object Oriented Design Quality Metrics: an analysis of dependencies,[2] у статті The Dependency Inversion Principle, що була опублікована у 1996 році в журналі C++ Report, а також у книгах «Agile Software Development, Principles, Patterns, and Practices» та «Agile Principles, Patterns, and Practices in C#».

Походження назви[ред.ред. код]

Традиційні методи проектування програмного забезпечення схиляють до створення програмних структур, у яких модулі вищого рівня залежать від модулів нижчого та у яких абстракції залежать від деталей реалізації. Ці методи, крім всього іншого, мають на меті визначення ієрархії підпрограм, які описують, як модулі вищого рівня здійснюють виклики до модулів нижчого рівня. Тому структура залежностей добре спроектованої об'єктно-орієнтованої програми «інвертована» по відношенню до структури залежностей, яка є результатом традиційних процедурних методів проектування.

Див. також[ред.ред. код]

Примітки[ред.ред. код]