Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Приклад дотримання DIP». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Коректне дотримання DIP** досягається тоді, коли модуль високого рівня залежить не від конкретного класу, а від абстракції, а конкретна реалізація підставляється ззовні. **Ключове:** `OrderService` (модуль високого рівня) залежить лише від інтерфейсу `OrderRepository`, а конкретні деталі реалізуються окремо і підставляються ззовні.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)ЗображенняКоректне дотримання DIP досягається тоді, коли модуль високого рівня залежить не від конкретного класу, а від абстракції, а конкретна реалізація підставляється ззовні. Нижче: правильний приклад. --- ### **Абстракція (контракт)** ```python class OrderRepository: def save(self, order): raise NotImplementedError ``` --- ### **Реалізації нижнього рівня** ```python class MySqlOrderRepository(OrderRepository): def save(self, order): print("Збереження в MySQL") class PostgresOrderRepository(OrderRepository): def save(self, order): print("Збереження в Postgres") ``` --- ### **Модуль високого рівня (не залежить від деталей)** ```python class OrderService: def __init__(self, repo: OrderRepository): self.repo = repo # залежить від абстракції def create_order(self, order): self.repo.save(order) ``` --- ### **Використання (впровадження залежності)** ```python repo = MySqlOrderRepository() service = OrderService(repo) service.create_order("order-1") ``` За потреби: ```python service = OrderService(PostgresOrderRepository()) ``` І жодних змін у OrderService. --- ### **Чому це дотримання DIP:** 1. **OrderService залежить від абстракції, а не від конкретного репозиторію.** Це означає, що бізнес-логіка не прив'язана до MySQL, Postgres чи будь-чого іншого. 2. **Конкретні реалізації залежать від абстракції, а не навпаки.** `MySqlOrderRepository` і `PostgresOrderRepository` реалізують один контракт. 3. **Можна змінювати інфраструктуру без зміни бізнес-коду.** Хочемо перейти на іншу БД? Просто створюємо нову реалізацію. 4. **Тестування стає простим.** Можна підставити мок: ```python class FakeRepo(OrderRepository): def save(self, order): print("Фейкове збереження") ``` 5. **Архітектура стає гнучкою і розширюваною.** --- ### **Підсумок** У цьому прикладі DIP дотримано: модуль високого рівня (`OrderService`) залежить лише від інтерфейсу (`OrderRepository`), а конкретні деталі реалізуються окремо і підставляються ззовні.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.