Как внедрение зависимостей не просто переносит сложность в отдельный класс?

9

На этой неделе я изучал использование среды Typhoon для внедрения зависимостей. Я понял, что разделение конструкции объектов полезно для замены произвольных компонентов на макеты во время модульного тестирования, и до сих пор я видел преимущества только от этого.

Но я не могу не думать, что раньше, когда у меня был огромный класс контроллера представления, который имел десятки импортируемых заголовков, теперь у меня есть огромный фабричный класс, который имеет десятки импортируемых заголовков. Должен ли я избежать массового фабричного класса?

dependency-injection Виктор
источник
6
Через десять лет я ожидаю, что я возьму список синглов из Синглтона, но на этот раз по веским причинам. У этого есть некоторые хорошие использования, но я предлагаю быть очень осторожным, оценивая воздействие.
Балог Пал
5
Я не думаю, что внедрение зависимостей - это способ уменьшить сложность, но способ избежать неявных зависимостей (использование глобальных символов / свободных переменных) в пользу явных зависимостей (используйте явные параметры / связанные переменные). Итак, сложность все еще существует, но вы вынуждены иметь дело с ней, потому что вы делаете это явным образом в сигнатурах вашего метода / конструктора.
Джорджио
7
Обратите внимание, что практически любая система организации кода может быть описана как «просто перенос сложности в другое место». Речь идет не столько об устранении сложности, сколько об организации ее наиболее логичным и полезным способом.
1
Если вам нужно импортировать 50 заголовков, вы должны сделать это где-нибудь. DI помогает вам с более простым способом модульного тестирования вашего кода.
BЈовић
2
Итак, вы говорите, что теперь ваш контроллер сосредоточен на контроле, а ваша фабрика импорта заголовков сосредоточена на импорте заголовков? Как это может быть плохо, используете ли вы DI-фреймворк или нет?
фунтовые

Ответы:

16

Внедрение зависимостей просто помогает определить, как один объект знает о другом зависимом объекте. Это не поможет вам снизить общую сложность системы. Если вам нужны десятки импортов до DI, вам все равно понадобятся десятки импортов после. Разница в том, что этот импорт будет в более удобном месте (классе) (фабрика, строитель и т. Д.).

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

Существует несколько принципов, которые похожи и часто используются вместе: внедрение зависимостей (DI), инверсия контроля (IoC) и принцип инверсии зависимостей (DIP)

Из этой статьи http://martinfowler.com/articles/dipInTheWild.html

DI - это проводка, IoC - направление, а DIP - форма

Сет М.
источник
2
+1, за последнюю цитату. Это лучшее разъяснение этих трех понятий, которые люди часто неправильно понимают.
Хайлем
Связанная статья выше действительно выдающаяся. Достаточно глубокое и очень четкое объяснение.
DemetriKots
10

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

Но я не могу не думать, что раньше, когда у меня был огромный класс контроллера представления, который имел десятки импортируемых заголовков, теперь у меня есть огромный фабричный класс, который имеет десятки импортируемых заголовков. Должен ли я избежать массового фабричного класса?

Вы должны избегать "огромных" классов, точка. Допустим, вы разделили контроллер представления на более мелкие, более обслуживаемые классы. Теперь все они несут ответственность за свои зависимости. DI помогает вам переместить это управление зависимостями из всех этих классов в класс фабрики / конфигурации, который отвечает только за управление зависимостями - см. Принцип единой ответственности. И хотя он, безусловно, будет гораздо менее «громоздким», чем оригинальный контроллер представления, если он становится слишком большим, у вас всегда есть возможность разделить его на более мелкие классы управления зависимостями, которые отвечают за различные части приложения.

Майкл Боргвардт
источник
2

По словам непрофессионала:

Инъекция зависимости перемещает сложность туда, где она приносит меньше вреда.

РЕДАКТИРОВАТЬ для @gnat: DI не просто переносит сложность в отдельный класс, он переносит его туда, где он причиняет меньше вреда.

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