Inversion of Control (IoC) и Dependency Injection (DI) — это фундаментальные принципы архитектуры программного обеспечения, особенно в объектно-ориентированных и компонентных системах. Они играют ключевую роль в обеспечении гибкости, расширяемости, тестируемости и слабой связности (loose coupling) компонентов системы.

🔹 Inversion of Control (IoC) — Инверсия управления

📘 Определение:

Inversion of Control (инверсия управления) — это принцип, согласно которому управление объектами и их зависимостями передаётся изнутри компонентов внешней сущности (например, фреймворка или контейнера).

📌 Суть:

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

📎 Пример без IoC:

class Service {
private Repository repository;
public Service() {
repository = new Repository(); // сам создаёт зависимость
}
}

Здесь Service жёстко зависит от Repository. Это мешает повторному использованию, тестированию и подмене зависимостей.

📎 Пример с IoC:

class Service {
private Repository repository;
public Service(Repository repository) {
this.repository = repository;
}
}

Зависимость передаётся извне — контроль инверсирован. Теперь Service не заботится, откуда берётся Repository.

🔹 Dependency Injection (DI) — Внедрение зависимостей

📘 Определение:

Dependency Injection (внедрение зависимостей) — это конкретный способ реализации IoC, при котором зависимости объекта передаются ему внешним образом (в конструкторе, через сеттер или интерфейс).

DI — это паттерн, а IoC — принцип. DI является реализацией IoC.

📌 Три основных способа внедрения зависимостей:

Конструкторное внедрение (Constructor Injection)

<br/>class Service {
private final Repository repo;
public Service(Repository repo) {
this.repo = repo;
}
}

Сеттер-инъекция (Setter Injection)

<br/>class Service {
private Repository repo;
public void setRepository(Repository repo) {
this.repo = repo;
}
}

Интерфейсное внедрение (Interface Injection)

<br/>interface Injectable {
void inject(Repository repo);
}

🔹 Контейнеры внедрения зависимостей

Для автоматизации DI используются контейнеры, например:

• **Spring Framework (Java)
  **
• **Dagger/Hilt (Android/Kotlin)
  **
• **Guice (Java)
  **
• **.NET Core DI container
  **
• **Koin (Kotlin)
  **
• **Unity (C#)
  **

Контейнер:

• Хранит зависимости.

• Умеет разрешать зависимости (resolve).

• Инжектит зависимости автоматически в объекты.

🔹 Преимущества IoC и DI

🔹 IoC против традиционного подхода

Традиционный подход:

Объекты сами создают свои зависимости:

Logger logger = new ConsoleLogger();

IoC:

Объекты получают зависимости от внешнего источника:

Logger logger = container.resolve(Logger.class);

🔹 Пример на Spring (Java)

@Component
public class UserService {
private final UserRepository userRepository;
@Autowired
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
}

Spring Framework автоматически внедрит UserRepository, если он также помечен как компонент (@Repository или @Component).

🔹 Пример на Hilt (Android)

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
@Inject lateinit var analytics: AnalyticsService
}

Зависимость будет автоматически внедрена Hilt через DI-контейнер.

🔹 Частые ошибки

1. **Слишком сложный граф зависимостей
   **

   • Большое количество зависимостей без контейнера приводит к "конструкторному аду".

2. **Нарушение SRP
   **

   • Если класс управляет зависимостями сам — нарушается принцип единственной ответственности.

3. **Скрытые зависимости
   **

   • Зависимости не передаются явно, а создаются внутри (антипаттерн).

🔹 Связь с SOLID

DI и IoC помогают реализовать следующие принципы:

• Single Responsibility Principle — объект не отвечает за создание зависимостей.

• Open/Closed Principle — можно расширять поведение через новые зависимости.

• Dependency Inversion Principle — объекты зависят от абстракций, а не реализаций.

🔹 IoC и DI в других языках

🔹 Заключительная концепция

• IoC — это общая идея: кто-то другой управляет зависимостями.

• DI — это конкретный способ реализации IoC: зависимости внедряются в объект извне.

• Эти подходы лежат в основе современного проектирования, способствуют созданию модульного, гибкого и тестируемого кода.