Что не так в моем объяснении DI и IoC?

Question

Вчера во время интервью меня спросили, что такое DI и IoC весной. Мой ответ был:

когда class(A) расширяет аннотацию class(B) или реализует interface(B) или создать объект class(B) любого класса в этом, то A Говорят, что зависит от B, Внедрение этой зависимости, то есть внедрение объекта в конструктор или метод сеттера, называется DI, и в этом процессе управление созданием объекта переходит во "внешний мир", такой как конфигурация XML, эта инверсия управления - IoC. DI не нужен МОК. Мы все еще можем иметь DI, когда нет МОК.

Интервьюер не согласился со мной - где я был не прав?

Еще кое-что-

Как мы использовали Super class reference variable или же coding through interface в конструкторе или параметре метода установки. Это как-то связано с DI/IOC или это только для достижения loose coupling?

Answer 1

IoC (версия Control) - абстрактное понятие. Это означает, что объекты не создают зависимые объекты напрямую, это получает извне области видимости объекта.

Существует несколько основных методов реализации инверсии управления.

• Используя фабричный образец
• Использование шаблона поиска сервисов
• Использование Inpendency Injection (DI), например
  • Конструктор инъекций
  • Параметр впрыска
  • Сеттер впрыска
  • Внедрение интерфейса
• Использование контекстного поиска
• Используя шаблонный метод проектирования шаблона
• Использование шаблона проектирования стратегии

Источник

Answer 2

Первое утверждение ***"когда класс (A) расширяет абстрактный класс (B) или реализует интерфейс (B)"***

Это наследование, которое не может быть внедрено как зависимость через Spring

Второе утверждение "создайте в нем объект класса (B) любого класса, тогда говорят, что A зависит от B"

звучит хорошо

"Внедрение этой зависимости, т. Е. Введение объекта в конструктор или метод установки, называется DI "

Непонятное утверждение для объяснения внедрения зависимости. Здесь значение инъекции необходимо объяснить. То есть Управление зависимостями обрабатывается контейнером Spring. Именно он контролирует их жизненный цикл и, таким образом, делегирует / вводит классы, которые их запрашивают (через конфигурационный файл Spring).

"его управление процессом создания объекта переходит во" внешний мир ", такой как конфигурация XML"

Здесь управление не идет ни во внешний мир, ни в файл конфигурации xml, но в контейнер Spring. И контейнер Spring использует этот файл конфигурации для своей работы.

"эта инверсия управления является IoC. DI не является необходимым IOC. У нас все еще может быть DI, когда нет IOC".

Хотя никаких проблем с этим, но кажется неполным. Здесь МОК нужно объяснить. Пытаясь объяснить это через изображение

Answer 3

Ваш ответ имеет смысл, и я разделяю то же мнение с небольшими отклонениями.

Концепция IoC была впервые услышана в эпоху процедурного программирования. Поэтому из исторического контекста IoC говорил об инверсии владенияпотоком управления, то есть кто несет ответственность за вызов функций в желаемом порядке - будь то сами функции или если вы должны инвертировать его в какую-то внешнюю сущность.

Однако как только появилось ООП, люди начали говорить о IoC в контексте ООП, где приложения занимаются созданием объектов и управлением отношениями между объектами, помимо потока управления. Такие приложения хотели инвертировать право владения созданием объекта (а не потоком управления) и требовали контейнера, который отвечает за создание объекта, жизненный цикл объекта и внедрение зависимостей объектов приложения, тем самым исключая объекты приложения из создания другого конкретного объекта.

В этом смысле DI - это не то же самое, что IoC, поскольку это не поток управления, но это своего рода Io *, т.е. инверсия владения созданием объекта.

Я уже обсуждал эту тему здесь.