Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Що означає принцип Dependency Inversion?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Принцип інверсії залежностей (Dependency Inversion Principle, DIP)** означає, що модулі високого рівня не повинні залежати від модулів низького рівня - обидва повинні залежати від абстракцій, а абстракції не повинні залежати від деталей, деталі повинні залежати від абстракцій. **Ключове:** DIP вимагає, щоб код залежав від абстракцій, а не від конкретних реалізацій, що робить систему гнучкою, замінною і стійкою до змін інфраструктури.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)ЗображенняПринцип інверсії залежностей (Dependency Inversion Principle, DIP) означає, що **модулі високого рівня не повинні залежати від модулів низького рівня - обидва повинні залежати від абстракцій. А абстракції не повинні залежати від деталей, деталі повинні залежати від абстракцій.** Детальніше: ### 1. Модулі високого рівня не повинні залежати від деталей Логіка застосунку (високий рівень) не повинна напряму залежати від конкретних реалізацій, наприклад: - конкретної БД, - конкретного HTTP-клієнта, - конкретного способу логування. Інакше зміна інфраструктури ламає бізнес-логіку. ### 2. Деталі повинні залежати від абстракцій Замість того щоб бізнес-код залежав від класу `MySqlRepository`, він повинен залежати від інтерфейсу `IRepository`. А вже конкретні реалізації (MySQL, Postgres, FileStorage) залежать від цієї абстракції. ### 3. Абстракції стабільні, реалізації мінливі DIP говорить: *Бізнес повинен спиратися на стабільні контракти, а мінливі деталі повинні підключатися до цих контрактів.* ### 4. Мета принципу - зменшити зв'язаність, - підвищити гнучкість архітектури, - спростити заміну реалізації, - дозволити тестувати модулі ізольовано. ### 5. Формулювання в одній фразі *Не бізнес-логіка повинна знати про технічні деталі, а технічні деталі повинні підлаштовуватися під бізнес-логіку через абстракції.* Підсумок: **DIP вимагає, щоб код залежав від абстракцій, а не від конкретних реалізацій. Це робить систему гнучкою, замінною і стійкою до змін інфраструктури.**Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.