DIP против DI против IoC

В течение примерно 2 месяцев я читал все, что мог найти для этих 3 тем, и я еще не уверен, что получил его.

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

Так как P в "DIP" означает "Принцип", я должен, вероятно, определить его следующим образом: Принцип инверсии зависимостей - это принцип, который требует, чтобы все ваши сущности кода зависели только от деталей, которые им действительно нужны,

"Детали, которые им действительно нужны" Я имею в виду интерфейсы для простейшего случая. Я также использовал слово "сущности", чтобы подчеркнуть, что DIP также применим к процедурам и что-то еще, а не только к классам.
Инъекция зависимостей. Он применим только к объектам с поддержкой DI. Объект с поддержкой DI - это объект, который "открыт" для настройки его поведения без изменения его внутренних компонентов. Существует 2 основных вида инъекций (когда речь идет о классах):
- Инъекция конструктора - это когда вы передаете все необходимые "абстрактные детали" объекту только к моменту его создания.
- Setter Injection - это когда вы "разъясняете" необходимые аспекты после того, как объект уже создан.
Таким образом, определение, вероятно, похоже на следующее: Dependency Injection - это процесс передачи "абстрактных деталей" сущности, которая действительно нуждается в этих деталях.

Под "действительно нужны эти детали" я имею в виду интерфейсы для простейшего случая. Слово "сущности", как всегда, используется, чтобы подчеркнуть, что DI также применим к процедурам и что-то еще.
Инверсия управления. Он часто определяется как "разница между библиотеками и фреймворками", как "написание программ так же, как вы делали в процедурном программировании" и т.д. Это самая запутанная вещь для меня. Я считаю, что основная идея здесь заключается в том, чтобы инициировать любые действия. Либо вы делаете что-то "когда захотите" (процедурный путь), либо "ждите", пока кто-то не спросит вас (путь IoC).

Мое определение: IoC является свойством потока выполнения вашей программы, когда вы ничего не делаете, пока не попросите вас сделать это.

Звучит точно так же, как "Голливудский принцип", но я считаю, что "Голливудский принцип" и IoC - абсолютно та же идея.

Насколько я понимаю?

Ответ 1

Я считаю, что это: DIP - это принцип, который ведет нас к DI. В принципе, целью является свободное соединение, и для его достижения есть как минимум два способа.

Инъекция зависимостей
Локатор сервисов

Однако Service Locator является анти-шаблоном и не имеет ничего общего с DIP. DI, однако, является правильным применением DIP.

Связь между DI и IoC была объяснена до.

Кстати, когда речь идет о DI и свободной связи, я нахожу терминологию, изложенную в Domain-Driven Design наиболее применимой. В принципе, Услуги - это единственные виды объектов, подвергнутых DI.

Ответ 2

My 20c, начните кодирование. У вас, вероятно, есть как минимум общее представление о том, как это работает. Кодирование доказательства концепции (POC) будет отличным способом увидеть, как все сочетается и работает в dev и время выполнения. Чтение займет у вас только до сих пор, и это действительно поможет сделать щелчок.

Если вы не знаете, с чего начать, большинство сообщений в блоге о DI содержат простые примеры, которые вы можете запустить. Не зацикливайтесь на том, какие рамки использовать (Unity, Spring, Castle Windsor и т.д.), Потому что это действительно не имеет значения для POC.