Здравствуйте, IQuerist, Вы писали:

IQ>О "наивном" DI и об архитектурном бессилии

IQ>Никогда я не имел желания холиварить на тему DI, т.к. во всех проектах, где обнаруживалось страстное желание автора использовать DI и над которыми мне приходилось работать, использование DI выглядело как совершенно очевидный антипаттерн и мне всегда было абсолютно не понятно для чего автор тратит время и силы ничего не получая взамен?

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

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

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

А как ещё учиться программистам? Только набивать шишки, анализировать свои ошибки, меняться.

IQ>Посмотрим на типичный пример наивного DI:
IQ>Ребята... вот эта низкоуровневая "требуха" это что ли "сервис"? Вот эти все "внутренности наружу" это инкапсуляция и архитектура? Как получилось, что попытка "соблюсти" принцип DIP очевидно вызывает нарушение всех остальных принципов SOLID и на это закрывают глаза? Как можно внедрять "зависимость сервиса" в ситуации, когда разработчик не способен создать сам внедряемый сервис? Проблема тут имхо базовая — разработчик не имеет навыков создания объектной декомпозиции и пытается компенсировать это использованием сложных механизмов, смысла которых он не понимает.

Разработчик рано или поздно избавится от этих кишок наружу — сначала спрячет их за фасадом, изолирует их, а потом ещё как-нибудь разделит — количество зависимостей между компонентами уменьшится. Но это уже мало имеет отношения к механизму внедрения зависимостей.

IQ>Лично для меня DI изначально был всего лишь удобным механизмом построения "плагинной архитектуры". Часть знакомых уверяла, что DI жизненно необходим для тестирования, но тут ситуация становилась совсем абсурдной, т.к. архитектурное решение (использовать DI) вроде как принималось, но никаких тестов при этом не было и в будущем они никогда не появлялись.

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

Это процесс итеративный, главное не надо думать, что ясная архитектура должна рождаться сразу. Код должен писаться, а потом читаться и правиться. Только после серии правок начнёт вырисоваться внятная схема взаимодействия объектов.

IQ>Как-то так... имхо главная начальная проблема DI — неспособность разработчиков создавать объектные декомпозиции. Это ведет к созданию абсолютно неправильной, очень низкоуровневой и хрупкой системы зависимостей нарушающей 4 из 5 принципов SOLID. Пример того, как некоторые пытаются лечить гланды через задний проход. Кстати неплохое название для антипаттерна — Colonoscopy Injection и для всей братии зомбированных шаблонами "наивных архитекторов" — архитект-проктолог.

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

Почему это названо проблемой конфигурации (внедрения зависимостей)? Конфигурация и архитектура не одно и то же.