Появление механизма внедрения зависимостей

Механизм внедрения зависимостей (Dependency Injection или DI) принадлежит к списку самых неправильно воспринимаемых концепций объектно-ориентированного программирования. Эта путаница широко распространена и касается терминологии, целей и механики. Должен ли этот механизм называться внедрением зависимостей, инверсией управления (Inversion of Control) или даже сторонним подключением (Third-Party Connect)? Является ли целью DI всего лишь поддержка модульного тестирования или же имеется более широкая цель? DI – это тоже самое, что и Service Locator? Нужен ли DI-контейнер?

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

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

Одной из основных причин противоречивости и неправильных советов является тот факт, что границы DI довольны нечеткие. Где заканчивается DI и начинаются другие концепции объектно-ориентированного программирования? Думаю, невозможно провести разграничительную линию между DI и другими аспектами написания качественного объектно-ориентированного кода. При обсуждении DI нам приходится вовлекаться в другие концепции такие, как SOLID и Clean Code. Не думаю, что я могу достоверно писать о механизме DI, не затрагивая при этом некоторых из этих других тематик.

Первая часть книги поможет вам осознать позицию DI по отношению к другим аспектам разработки программного обеспечения – заявляя, таким образом, о нем на всеуслышание.

Первая глава предоставляет вам быстрый обзор DI, охватывая его цели, принципы и преимущества, а также предоставляя набросок области ее применения для остальной части книги. Если вы хотите узнать, что такое DI и почему этот механизм должен вас заинтересовать, то это как раз то, с чего вам следует начать. Содержание главы предполагает, что у вас нет никаких первичных познаний DI, но даже если вы уже знали о ней, вы все еще можете иметь желание прочитать ее – может оказаться, что ее содержание отлично от того, что вы ожидали.

Первая глава сфокусирована на общей картине представления и не вдается в детали. Глава 2, с другой стороны, всецело зарезервирована под крупный пример. Подразумевается, что этот пример даст вам намного больше конкретного понимания DI. Он разделен на две части и сформирован практически в виде комментария. Для того чтобы противопоставить DI другим "традиционным" стилям программирования, глава сначала демонстрирует типичную, сильно связанную реализацию шаблонного приложения, а впоследствии заново реализует его с помощью DI.

Третья и конечная глава части 1 вводит понятие DI-контейнера и объясняет, как оно вписывается в общую картину представления DI. Я обсуждаю DI в общих понятиях и, несмотря на то, что я предоставляю примеры кода, которые демонстрируют, как работает типичный DI-контейнер, целью главы не является объяснение деталей конкретного API. Главная цель главы 3 – показать, что DI-контейнер является довольно полезным, необязательным инструментом. Вполне допустимо использовать DI без использования DI-контейнера, поэтому части 2 и 3 более или менее игнорируют DI-контейнеры и вместо этого обсуждают DI, не затрагивая контейнеры. Далее в части 4 мы возвращаемся к понятию DI-контейнера с целью анализа четырех конкретных контейнеров.

Часть 1 определяет контекст всей остальной книги. Она нацелена на читателей, которые не имеют первичных познаний DI, но опытные специалисты, использующие DI, могут также приобрести полезные знания, просматривая главы с целью получить понимание терминологии, используемой в рамках всей книги. К концу части 1 вы должны приобрести прочное понимание словаря и общих понятий, даже если некоторые конкретные детали все еще слегка расплывчаты. Ничего страшного – книга становится более конкретной на протяжении ее чтения, поэтому части 2, 3 и 4 должны будут ответить на вопросы, которые, скорее всего, появятся у вас после прочтения части 1.

"Дегустационное меню" механизма внедрения зависимостей

Комплексный пример

DI-контейнеры

или RSS канал: Что новенького на smarly.net