Вопрос проверяет понимание одного из базовых принципов современной архитектуры приложений.
Inversion of Control — это принцип, при котором управление созданием и связыванием объектов передается фреймворку.
Код перестает самостоятельно управлять зависимостями.
Это снижает связанность компонентов.
IoC упрощает тестирование и расширение системы.
Inversion of Control — это архитектурный принцип, а не конкретная технология.
Inversion of Control означает, что управление потоком выполнения и созданием объектов передается контейнеру или фреймворку.
Код больше не решает:
Когда создавать зависимости
Какие реализации использовать
Как связывать объекты
Без IoC:
Service service = new Service(new Repository());
Класс жестко связан с конкретной реализацией.
С IoC:
@Service
class Service {
private final Repository repository;
public Service(Repository repository) {
this.repository = repository;
}
}
Контейнер сам подставляет нужную реализацию.
IoC дает:
Слабую связанность
Возможность подмены реализаций
Простое тестирование
IoC переворачивает ответственность за управление объектами.
Это основа большинства современных фреймворков.