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