Dependency Injection на пальцах?

Question

[Михаил Макаров]

Объясните, пожалуйста, принцип внедрения зависимости "на пальцах". Сколько ни перечитал статей, - не врубаюсь.

Answer 1

[stratosmi]

Ну вот нужно тебе использовать какой то функционал. Реализованный в виде класса, функции и т.п.

Если ты будешь явно вызывать эту функцию, обращаться к классу - это явная зависимость.

Но если тебе передать эту функцию или класс как переменную - это внедренная зависимость.

То есть сегодня одну функцию/класс передали, завтра другую (лишь бы они были совместимы по сигнатуре) - твоя программа даже разницы не заметит.

Answer 2

[Alex Wells]

DI позволяет создать единый "реестр", где вы можете указать какие классы будут синглтонами (и.е. один и тот же экземпляр каждый раз), а какие создаваться фабриками (и.е. каждый раз создавать новый экземпляр). Более того, в тех же классах вы можете "подтягивать" нужные вам зависимости (экземпляры классов) просто указывая нужный класс, а DI берет на себя работу того, как именно он получит эти экземпляры. Он упрощает вам жизнь, ибо вы можете один раз указать ЧТО вам нужно вместо того, что бы получать это самому. Более того, в любой момент вы можете подменить одну зависимость на другую. Например, есть у вас интерфейс и два класса его реализующие. Во всем приложении вы общаетесь только с интерфейсом, а в DI вы указываете какой из них будет использоватся, причем это можно менять "на лету".

Кроме того вы можете строить бесконечные дерева зависимостей классов и даже делать два класса зависимыми один от другого, указывая правила их резолвинга в DI.

Answer 3

[oldhowl]

1. SOLID, а конкретно буква D - Dependency inversion principle, который гласит что 'When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. ', одно из следствий - если тебе в коде нужна зависимость, не нужно создавать её руками, проси чтобы её тебе передали сверху, иначе код будет супер-связный (это плохо)
2. Когда ты пишеь по SOLID и выносишь в конструктор все эти зависимости которые тебе нужны, ты просто офигеешь в продакшене создавать такие классы руками, var a = new A(new B(new C()), new D(), new E()...
3. Код написанный по SOLID проще тестить, т.к. легко замокать все зависимости
4. Это дает некоторую гибкость например в настройке окружения для разных тенантов - ты можешь в одном месте в контейнере, подсовывать разные реализации
5. Чисто визуально, проще смотреть от чего код зависит, смотришь на конструктор и понимаешь что других зависимостей там нет
6. Контейнер может управлять процессом создания объектов - нужно ли всегда один и тот же возвращать или нужно каждый раз по новой создавать

Answer 4

[Сергей Горностаев]

Архитектурные вопросы сложны по определению. Чтобы их понимать, нужно иметь достаточную базу знаний и опыта программирования. В идеале, чтобы понять паттерн, нужно столкнутся с проблемой, для решения которой он был придуман. Если база знаний и опыта уже есть, а понимания всё ещё нет, то прочитайте учебник, вроде "Чистой архитектуры" Мартина.

А "на пальцах" вам сейчас дадут множество объяснений, большинство которых будут неправильными и запутают ещё больше.