Запропонувати правку

Покращити цю статтю

Допрацюйте відповідь до «Приклад порушення DIP». Ваші зміни проходять модерацію перед публікацією.

Потрібне підтвердження

Контент

Що ви змінюєте

Заголовок (UA)

Коротка відповідь (UA)

Показується над повною відповіддю для швидкого нагадування.

Відповідь (UA)

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

Ось типовий приклад порушення:

---

### **Приклад порушення DIP**

```python
class MySqlOrderRepository:
    def save(self, order):
        print("Збереження замовлення в MySQL")

class OrderService:
    def __init__(self):
        self.repo = MySqlOrderRepository()  # порушення DIP

def create_order(self, order):
        self.repo.save(order)
```

---

### **Чому це порушення DIP:**

1. **Високорівневий модуль залежить від низькорівневого**
`OrderService`: бізнес-логіка.
`MySqlOrderRepository`: інфраструктура.
Бізнес-логіка знає про технічні деталі, що порушує DIP.
2. **Не можна замінити реалізацію без переписування OrderService**
Хочемо перейти на Postgres?
Потрібно змінювати конструктор:

```python
  self.repo = PostgresRepository()
  ```
Це ламає принцип відкритості/закритості і робить код крихким.
3. **Складно тестувати OrderService**
Не можна підставити фейковий репозиторій чи мок: він жорстко зашитий.
Тести неможливі без реальної БД.
4. **Бізнес-код залежить від деталей, які часто змінюються**
Репозиторій, драйвери, бібліотека з'єднань змінюються.
Бізнес-логіка повинна бути стабільною.
Пряма зв'язка ламає архітектуру.

---

### **Підсумок**

`OrderService` повинен залежати від абстракції, а не від конкретного класу.
У цьому прикладі бізнес-логіка жорстко прив'язана до MySQL: це пряме порушення принципу інверсії залежностей.

Markdown · перетягуйте зображення · ⌘B / ⌘I шорткати178 слів

Для рев’юера

Примітка для модератора (необов’язково)

Бачить лише модератор. Прискорює рев’ю.