В чем реальная разница между "инъекцией ублюдка" и " инъекцией бедняка"


из книги "инъекция зависимостей в .Net" я знаю, что граф объектов должен быть создан в Композиция Root приложения, которое имеет большой смысл для меня, когда вы используете контейнер IoC.

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

теперь, учитывая все это, я бы сказал, что "инъекция бедного человека" будет просто не использовать контейнер IoC и вместо этого кодировать весь граф объектов вручную на упомянутом Композиция Root.

Итак, мои вопросы:

  1. правильно ли я понимаю эти понятия или я совсем сбились с пути?
  2. Если вам все еще нужно зарегистрировать все зависимости в контейнере IoC против кодирования их вручную в том же самом корне композиции, в чем реальная выгода использования контейнера IoC?
  3. если я неправильно понял, что такое" инъекция бедного человека " на самом деле, может кто-нибудь прояснить это?

спасибо

3 54

3 ответа:

когда дело доходит до DI, там много противоречивого использования терминологии. Термин бедняга Ди не является исключением. Для некоторых людей это означает одно, а для других-что-то другое.

одна из вещей, которые я хотел сделать с книгой, чтобы поставить последовательный язык шаблонов для DI. Когда дело дошло до всех этих терминов с противоречивым использованием, у меня было два варианта: придумать совершенно новый термин или выбрать наиболее распространенный используйте (по моему субъективному мнению).

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

по крайней мере, я нахожу это обнадеживающим, что книга, похоже, сделала свою работу по объяснению точно обоих Ди бедняги и инъекция ублюдка, потому что интерпретация, данная В О. П., точна.

Что касается реальной выгоды от контейнера DI, я отсылаю вас к этому ответу:аргументы против инверсии контейнеров управления


П. С. 2018-04-13: Я хотел бы отметить, что я много лет назад пришел к признанию, что термин бедняга Ди делает бедный (sic!) работа по сообщению сути принципа, поэтому вот уже много лет я вместо этого назвал его Pure DI.

некоторые примечания к части 2) вопроса.

Если вам все еще нужно зарегистрировать все зависимости в контейнере IoC против кодирования их вручную в том же корне композиции, в чем реальная выгода использования контейнера IoC?

  • Если у вас есть дерево зависимостей (классы, которые зависят от зависимостей, которые зависят от других зависимостей и т. д.): Вы не можете делать все "новости" в корне композиции, потому что вы новичок экземпляры на каждом конструкторе" bastard injection " каждого класса, поэтому есть много "корней композиции", разбросанных по вашей базе кода

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

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

все это, помимо других очевидных преимуществ, предоставляемых DI (тестируемость, ремонтопригодность, развязка кода, расширяемость...)

мы обнаружили, что при рефакторинге устаревших приложений и разделении зависимостей, что вещи, как правило, проще, когда делается с помощью двухэтапного процесса. Этот процесс включает в себя как" бедный человек", так и формальные контейнерные системы МОК.

во-первых: настройка интерфейсов и установить "бедный человек МОК" для их реализации.

  • это развязывает зависимости без дополнительных накладных расходов (и обучения кривая) формальной установки МОК.
  • Это также уменьшает помехи существующий устаревший код. Ничто так не вводит еще один набор проблем для отладки.
  • члены команды разработчиков никогда не находятся на том же уровне знаний или понимания. Таким образом, это экономит много времени реализации.
  • Это также позволяет опору для тестовых случаев.
  • это также устанавливает стандарты для формальной контейнерной системы МОК позже.
  • это может быть реализовано поэтапно с течением времени многими людьми.

Во-Вторых: Каждый Система МОК имеет плюсы и минусы.

  • теперь, когда стандарт применения установлен, образованное решение может быть сделано в выборе контейнерной системы IoC.
  • реализация системы МОК становится задачей замены кода" бедных людей " с помощью новая система МОК.
  • Это может быть реализовано поэтапно с течением времени и параллельно с "бедным человеком". Лучше возглавить это с одним человеком.