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

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

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

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

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

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

спасибо

3 54
oop dependency-injection architecture

3 ответа:

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

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

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

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

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

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

45

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

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

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

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

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

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

4

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

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

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

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

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