DI

DI (Dependency Injection) — подход, который абстрагирует создание объекта, выделяя его на отдельный слой и отделяя от основного приложения.
Добавляет концепцию управления зоной использования (scope) и временем жизни объекта.

При том важно разделять:
🔹Composition Root (CR) — паттерн, подход при котором создание объектов системы происходит в одном месте.
Выделяет 3 (RRR) фазы управления жизненным циклом объектов:
- Register — создание зависимостей
- Resolve — решение графа зависимостей
- Release — удаление, освобождение объекта

🔹DI container (DIc 🍆) — как правило плагин, реализация-автоматизация CR.
Т.е. вместо ручного создания и решения графа зависимостей, он через рефлексию или кодогеном сам прокидывает зависимости в конструктор или поля.

🔹Service Locator (SL) — создает, хранит и отдает по требованию любое множество зависимостей
Может быть частью реализации CR, но тогда решать граф нужно самому.
В этом месте, при не понимании RRR, возникает куча проблем (кольцевые зависимости, классы боги) из-за чего SL называют антипаттерном.

Из этого следует:
▫️Реализовать DI можно без использования DIc
▫️DIc (Zenject, Vcontainer и др.) сильно расширяют жизненный цикл любого класса
▫️С DIс мы делегируем обязанность по созданию и управлению жизненным циклом объекта!
▫️Легковестной реализацией DI может быть SL (статический класс со словарем)

При использовании DIc или SL важно навсегда запомнить:
1. Никакой логики в конструкторе. Только агрегация и композиция
2. Вся логика инициализации, как отдельная стадия создания объекта, выделяется в отдельный метод

В случае несоблюдения мы рискуем обратиться к зависимости раньше, чем был решен граф, что сразу == куча головняка с порядком регистрации зависимостей.

Картинка из книги Dependency Injection Principles, Practices, and Patterns by Steven van Deursen and Mark Seemann

#проект_в_разработке@UniArchitect
#аббревиатуры@UniArchitect