TLDR
Эмпирические данные не имеют значения. Инструменты и практики (например, DI) решают конкретные проблемы. Поймите свои проблемы, узнайте, как использовать инструменты, и это станет очевидным, когда инструмент будет полезен - и вы сможете объяснить результаты гораздо более пророчески, чем любые обобщенные, агрегированные, эмпирические данные.
А теперь, с гораздо большим многословием ...
Есть ли эмпирические доказательства?
Конечно, наверное. Или, по крайней мере, может быть. Но кого это волнует? Это не актуально.
Статистический анализ затрат и выгод DI может быть интересен академически, но он не обязательно предсказывает индивидуальный успех. Совокупные результаты скрывают индивидуальные успехи и неудачи. И я могу утверждать, что данные о «евангельских» практиках особенно ядовиты. Эти дисциплины, как правило, привлекают как фанатиков, так и дураков, которые затеняют чистое влияние «чистой» реализации, и любой из которых вы можете быть!
Итак, как мы узнаем, что инъекция зависимостей вообще полезна ?
Хороший вопрос! БОЛЬШОЙ вопрос, на самом деле. И я с тобой - я ненавижу тратить время и умственные усилия на догматические "лучшие практики", которые никто не может оправдать. Итак, я рад, что вы спросили.
Гм. Но вот смущающая проблема ... В общем , вы не знаете. И, что еще более неловко, ваш код может на самом деле не стать лучше, введя DI.
GASP!
⊙▃⊙ . . . (╯°□°)╯︵ ┻━┻
...
Итак, может быть, теперь вам интересно ...
Почему я должен беспокоиться о вещах, которые не были доказаны?
Прежде всего, давайте все просто - на каждой стороне дебатов - просто успокоиться. Я могу заверить вас, что между догматизмом и скептицизмом лежит прекрасный рай разума и рассудительности. (И иногда эксцентричный пост SE.SE.) И, POAP может привести вас туда.
... Под чем я подразумеваю принцип применения принципов :
Принципы, модели и практики не являются конечными целями. Поэтому хорошее и правильное применение каждого из них вдохновлено и ограничено более высокой, более конечной целью.
Вы должны понимать, почему вы делаете то, что делаете!
(POAP не освобождается от POAP.)
(Я бы сказал, «выделение мое», но в любом случае это из моего собственного «блога». Итак, это все мое!)
Позвольте мне повторить главное: вам нужно понять, почему вы делаете то, что делаете.
И, возможно, чтобы уточнить, как правило, не имеет смысла брать какое-то данное «что-то» (например, инъекцию зависимости) и использовать его, не понимая, какую проблему оно решает - специально для вас. Если вы понимаете свои проблемы и то, как работает «что-то» (например, DI), будет несколько «очевидно», насколько полезно «что-то», в значительной степени независимо от того, что предлагают обобщенные, агрегированные, эмпирические данные.
Если полезность DI или ООН -helpfulness вам не очевидно , - или , по крайней мере , за пределами ваших рассуждений полномочий - вы либо не понимаете , DI, или вы не понимаете , ваши собственные проблем.
Давайте рассмотрим реальную притчу.
Нам нужно построить коробку. У нас есть дерево. У нас есть гвозди. И у нас есть два инструмента: стандартный молоток с раздвоенным хвостом и отвертка .
Теперь у нас могут быть некоторые обширные эмпирические данные, чтобы показать, что коробки, изготовленные с помощью отверток, в целом значительно более надежны, чем коробки с молотками. Но, если вы попытаетесь ввернуть эти гвозди, у вас не останется коробки. И, если вы попытаетесь ударить их отверткой, вы можете в конечном итоге получить их; но это потребует значительно больше времени и усилий, и конечный результат будет менее точным (и надежным), чем если бы вы просто использовали молоток.
И, если вы когда-либо видели, чтобы кто-то использовал какой-либо инструмент раньше, и если вы понимаете, как выглядит коробка, решение очевидно.
Телекинез!
Эээ ... хм ...
Да-а, какую проблему решает Dependency Injection?
Он работает для предотвращения жесткого, неконфигурируемого кода, который часто поэтому не поддается проверке .
Это делается путем разрешения вызова кода для определения объектов, с которыми работает модуль. И я знаю, что вы думаете об этом, и вы правы: это даже не новая концепция. Параметры метода / функции существуют с момента появления алгебры.
Мы начали евангелизировать базовую передачу параметров, назвав ее «Внедрение зависимостей», когда накопили и унаследовали достаточно кода, чтобы увидеть наши дисбалансы. Горы кода, над которыми мы сидели, не могли быть легко изменены, протестированы или даже использованы повторно просто потому, что зависимости были скрыты.
Следовательно, ревностный крестовый поход для инъекции зависимости ...
К. Но я могу передать аргументы в порядке. Почему рамки ?
Насколько я понимаю, структуры DI в первую очередь решают проблему накопления шаблонов (из-за чрезмерно усердного DI, IMO) - особенно, когда существуют стандартные зависимости «по умолчанию» для всех модулей, которые в них нуждаются. DI-фреймворки совершают магические (потенциально даже порочные) вещи, чтобы вытащить эти зависимости по умолчанию, когда они явно не передаются в момент вызова. (Имейте в виду тот же эффект, что и при использовании локатора услуг при использовании таким образом!)
Инъекция зависимости, как «дисциплина», на самом деле очень трудно понять правильно. Это не вопрос использования DI или нет; это вопрос зная , какая зависимость, вероятно, изменения или необходимости насмешек и инъекционных тех . И затем, вопрос о том, подходит ли DI лучше, чем какая-либо альтернатива, например, Service Location ...
Но, я призываю вас к нагуглить , может увидеть этот SO ответ , возможно , поговорить с супер-опытный и успешный разработчик в вашей отрасли, и разместить примеры конкретных для CR.SE .