Warning. В результате срача дисксиий, пробелы автора в понимании сути DI были заполнены (см. Update 4 внизу). Претензии высказанные в посте по отношению к DI оказались претензиями к DI фреймворкам.
Никогда я не имел желания холиварить на тему DI, т.к. во всех проектах, где обнаруживалось страстное желание автора использовать DI и над которыми мне приходилось работать, использование DI выглядело как совершенно очевидный антипаттерн и мне всегда было абсолютно не понятно для чего автор тратит время и силы ничего не получая взамен?
Собственно ситуация имхо довольно типичная — мне то "опыт подказывает", а молодежь старательно "набивает шишки", но при этом, я почему-то сходу не нашел ни одного внятного объяснения от популяризаторов DI того, почему наивное использование DI будет провальным. Поэтому я решил таки сформулировать свой вариант
Посмотрим на типичный пример наивного DI:
public class HomeController : Controller
public HomeController(
IBoringItemDataReader,
IBoringItemDataWriter,
BoringItemChildDataReader,
IBoringItemChildDataWriter,
IAppDataJsonConverter,
...
)
Гиперболизируя можно было бы добавить еще IJsonConverter чтобы механизм конвертирования json можно было изменить и что ни будь вроде IDateTimeProvider, работа с датой и временем вряд ли поменяется, но на всякий случай стоит "уменьшить зависимости" .
Посмотрим на реализацию IBoringItemDataReader:
public class BoringItemDataReader : IBoringItemDataReader
и с десяток совершенно очевидных хелперных stateless методов типа:
Ребята... вот эта низкоуровневая "требуха" это что ли "сервис"? Вот эти все "внутренности наружу" это инкапсуляция и архитектура? Как получилось, что попытка "соблюсти" принцип DIP очевидно вызывает нарушение всех остальных принципов SOLID и на это закрывают глаза? Как можно внедрять "зависимость сервиса" в ситуации, когда разработчик не способен создать сам внедряемый сервис? Проблема тут имхо базовая — разработчик не имеет навыков создания объектной декомпозиции и пытается компенсировать это использованием сложных механизмов, смысла которых он не понимает.
Лично для меня DI изначально был всего лишь удобным механизмом построения "плагинной архитектуры". Часть знакомых уверяла, что DI жизненно необходим для тестирования, но тут ситуация становилась совсем абсурдной, т.к. архитектурное решение (использовать DI) вроде как принималось, но никаких тестов при этом не было и в будущем они никогда не появлялись.
Как-то так... имхо главная начальная проблема DI — неспособность разработчиков создавать объектные декомпозиции. Это ведет к созданию абсолютно неправильной, очень низкоуровневой и хрупкой системы зависимостей нарушающей 4 из 5 принципов SOLID. Пример того, как некоторые пытаются лечить гланды через задний проход. Кстати неплохое название для антипаттерна — Colonoscopy Injection и для всей братии зомбированных шаблонами "наивных архитекторов" — архитект-проктолог.
Update:
Обсуждение натолкнуло на мысль, что на самом деле наивный DI нарушает принцип DIP в первую очередь. Т.к. каноничная формулировка DIP гласит:
Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
имхо совершенно очевидно, что наивный сервис слепленный из хелперных методов DAL, ни в коем случае не является "абстракцией". Он предельно конкретный с предельно конкретными entity типами даже если структура этих типов продублирована, а данные копируются с помощью мапперов (эдакий карго-культ "абстрации"). Имхо здесь совершенно четко определяемая проблемы — интерфейсы верхних уровней начинают определять низкоуровневые интерфейсы DAL. Разрозненные хелперные методы не перестанут быть хелперными методами от того, что их вызывают через интерфейс.
Update 2:
Не стоит ждать в этом топике борьбы за рассовую чистоту DI, здесь рассматривается совсем другой аспект. Возможно аспект не очень грамотный (с точки зрения тех кто хорошо разбирается в теме DI и давно его использует), но уж какой есть. Имхо нельзя игнорировать тот факт, что из за базза поднятого вокруг DI фреймворков их пытаются использовать не так и не там полностью игнорируя негативные результаты.
Вот в чем проблема и смысл топика, а вовсе не в том, что люди которым приходится отхреначивать DI из провальных проектов как-то не очень правильно понимают идеи DI.
Update 3
Мое имхо по итогам обсуждения поста:
Ребята это секта... секта свидетелей DI фреймворков, отпочковавшаяся от секты свидетелей TDD. Вообще имхо DI фреймворки появились из за того, что сектантам TDD было необходимо тестировать приватную логику, а по их канонам unit test этого делать нельзя. Поэтому был применен ряд шельмований, приватную логику перекрестили в сервисы вытащили их наружу. Здесь можно вспомнить COM, который решает аналогичные DI фреймворкам задачи, но в те времена не было движения TDD и поэтому COM не стал религией, а остался инфраструктурным решением.
Ни DI ни TDD ничего не гарантируют разработчику, ни от чего не защищают и ни в чем не помогают. Зато гарантированно служат серьезным источником оверхеда. Как же им удается иногда демонстрировать свою полезность? А все элементарно... например код веб систем, можно разделить на две части — бизнес логика и код взаимодействия с системными сервисами UI, DB и т.д. Взаимодействие с системными сервисами разработчику понятно, отлично проработано и имеет долгую историю. Что провоцирует наивные умы, особенно на первых этапах проекта, запихивать бизнес логику прямо в код который реализует взаимодействие с системными сервисами. Так создаются шедевры спагетти кода. Что делает TDD? Оно постулирует — сначала пишем тесты. Все верно, в юнит тестах нет взаимодействия с системными сервисами поэтому структуру бизнес логики приходится прорабатывать отдельно от всего т.е. приходится строить архитектуру. Вот и весь трюк. Цена такого подхода — значительный оверхед кода (уровень которого зависит от религиозного фанатизма разработчика), потому как бизнес логика гарантированно будет уточнятся и изменяться и тесты придется переписывать, но как мы теперь понимаем, для проработки бизнес логики и построения архитекуры тесты на самом деле лишь полезны, но никак не обязательны.
Update 4 (вероятно крайний)
После сосредоточения на теме обнаружился забавный баг. DI на деле выглядит примерно так:
public SomeClass (MyClass myObject)
{
this.myObject = myObject;
}
и не требует никаких интерфейсов, фреймворков, code-дуделок и code-перделок (думаю практически все, так или иначе используют этот паттерн). А все остальное от лукавого.
Хвала stackoverflow бельгийцы (!) сохранили способность воздерживаться от троллинга и сектантщины.
Особую благодарность хочу выразить ".", хотя клизьма с троллингосептом ему тоже не повредит .
Т.е. все мои претензии высказанные в посте по отношению к DI стоит считать претензиями к DI фреймворкам. И получается любопытный вывод — если с простым DI ваши проекты, с завидным постоянством превращаются в big ball of mud, то как использование DI фреймворка может это предотвратить?
Здравствуйте, IQuerist, Вы писали:
IQ>Гиперболизируя можно было бы добавить еще IJsonConverter чтобы механизм конвертирования json можно было изменить и что ни будь вроде IDateTimeProvider, работа с датой и временем вряд ли поменяется, но на всякий случай стоит "уменьшить зависимости" .
Это еще ничего. Вот когда начинают эти зависимости внедрять через всякие xml конфиги, вот тогда действительно зашкаливает
Здравствуйте, IQuerist, Вы писали:
IQ>Как-то так... имхо главная начальная проблема DI — неспособность разработчиков создавать объектные декомпозиции. Это ведет к созданию абсолютно неправильной, очень низкоуровневой и хрупкой системы зависимостей нарушающей 4 из 5 принципов SOLID. Пример того, как некоторые пытаются лечить гланды через задний проход. Кстати неплохое название для антипаттерна — Colonoscopy Injection и для всей братии зомбированных шаблонами "наивных архитекторов" — архитект-проктолог.
Напишите на Reddit, только чуть более подробно. Как именно набивают шишки, какая декомпозиция правильная, а какая — нет, с примером. Не обязательно правильным, даже наборот, если будет криво — тем лучше для холивара. Выражение Colonoscopy Injection следует вынести в заголовок статьи, термин у вас получился совершенно убойный. Даже если со статьей не согласятся, термин пойдет в народ и DI будет надежно обгажено, туда ему и дорога.
Здравствуйте, 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 и для всей братии зомбированных шаблонами "наивных архитекторов" — архитект-проктолог.
Это нормальный процесс разработки. Мало кто способен создавать адекватные объектные декомпозиции сразу. Сначала пишется говнокод, решающий задачу, потом он причёсывается, чтобы быть готовым к последующим изменениям в решении задачи. На это требуется время, если давить на коллег и требовать реализации новых фич вместо переделки старых, то говнокод будет долго жить в программе. С опытом программисты научатся отстаивать это время на переделки и код будет выглядеть лучше и проще.
Почему это названо проблемой конфигурации (внедрения зависимостей)? Конфигурация и архитектура не одно и то же.
IQ>Кстати неплохое название для антипаттерна — Colonoscopy Injection и для всей братии зомбированных шаблонами "наивных архитекторов" — архитект-проктолог.
Перевод гугля совершенно "убойный"...
Колоноскопия Инъекции
Кстати, давайте уж сразу русское токование...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, IQuerist, Вы писали:
IQ>Ребята... вот эта низкоуровневая "требуха" это что ли "сервис"? Вот эти все "внутренности наружу" это инкапсуляция и архитектура?
Как мне кажется, этот момент — следствие попытки натянуть "классический" DI на все остальные области. Классический — это который пошёл от тяжёлых продуктов с продвинутым public API и поддержкой плагинов от сторонних разработчиков. Вот там возможность подсунуть нужные сервисы в код минимумом телодвижений — то, что надо.
К сожалению, DI в чистом виде абсолютно непригоден для использования в тяжёлом биз-коде. Там от DI требуется не закинуть сервисы и отдать объект, а способ протащить эти сервисы по длиннющей цепочке вызовов, причём состав зависимостей часто заранее неизвестен и определяется в рантайме. Для дотнета обсуждали вот тут
IQ>Часть знакомых уверяла, что DI жизненно необходим для тестирования, но тут ситуация становилась совсем абсурдной, т.к. архитектурное решение (использовать DI) вроде как принималось, но никаких тестов при этом не было и в будущем они никогда не появлялись.
Вот да-да-да. На практике DI сам по себе никак не помогает и не упрощает процесс тестирования. Сложный код с полудесятком зависимостей одинаково неприятно покрывать тестами, что с DI, что без. Простой вообще не должен требовать DI для тестов
IQ>Как-то так... имхо главная начальная проблема DI — неспособность разработчиков создавать объектные декомпозиции.
+1, только я бы немного по-другому сформулировал. Фраза "я добавил возможность" на уровне архитектуры на самом деле означает "теперь нам всем придётся это использовать". Сам по себе DI экономит кучу времени, но только до момента, когда он не вылезает из своей родной ниши. После этого лучше смотреть в сторону других инструментов.
UPD, P.S. Не стоит налегать на SOLID как на аргумент в спорах. Его к сожалению воспринимают как волшебную палочку, хотя на практике подход "потому что SOLID" работает не лучше, чем самолёт из культа карго. Голову никто не отменял
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, IQuerist, Вы писали:
IQ>>Как-то так... имхо главная начальная проблема DI — неспособность разработчиков создавать объектные декомпозиции. Это ведет к созданию абсолютно неправильной, очень низкоуровневой и хрупкой системы зависимостей нарушающей 4 из 5 принципов SOLID. Пример того, как некоторые пытаются лечить гланды через задний проход. Кстати неплохое название для антипаттерна — Colonoscopy Injection и для всей братии зомбированных шаблонами "наивных архитекторов" — архитект-проктолог.
С>Напишите на Reddit, только чуть более подробно.
Я честно говоря не очень в курсе, как "продвигать идею" в современном IT сообществе
С>Как именно набивают шишки, какая декомпозиция правильная, а какая — нет, с примером. Не обязательно правильным, даже наборот, если будет криво — тем лучше для холивара.
Шишки набивают очень просто когда неделями бьешься с абстракциями которые сам создал и при этом они очевидно деградируют, что бы ты не делал и при этом еще и вину свалить не на кого
Про "правильную декомпозицию" имхо не пишут статей, про нее пишут докторскую диссертацию
С>Выражение Colonoscopy Injection следует вынести в заголовок статьи, термин у вас получился совершенно убойный.
Ну с общей помощью надеюсь, антипаттерн пойдет в массы. Потому как ситуация с наивным DI просто абсурдная.
С>Даже если со статьей не согласятся, термин пойдет в народ и DI будет надежно обгажено, туда ему и дорога.
я не имел цели "обгадить DI" для "плагинной архитектуры" это прекрасное решение см. COM и OLE. Меня просто в очередной раз взбесило нежелание (типичное?) отдельных программистов немного подумать над тем, что они делают.
Здравствуйте, vsb, Вы писали:
vsb>Так что вы предлагаете, учитывая, что тестировать надо? Я пока ничего лучше DI не видел.
Я предлагаю не принимать архитектурные решения в рассчете на "сервисы" (тестирование), которые с крайне высокой долей вероятности никогда не будут реализованы.
Здравствуйте, Vladek, Вы писали:
V>Автор ещё не продумал решение, но хочет снизить риски, связанные с конфигурированием программы впоследствии. Конечно, собирание зависимостей в единое дерево объектов слабо влияет на простоту и понятность этого дерева, однако всё же позволяет сразу увидеть из каких компонентов программа состоит и управлять конфигурацией.
снижение рисков с помощью нарушения SOLID?
V>Я предполагаю, что внедрение зависимостей используется так: при запуске программы создаётся контейнер, в нём регистрируются сразу все компоненты, контейнер создаёт дерево зависимых компонентов, способное жить самостоятельно, и завершает свою работу (умирает). Компоненты далее работают сами по себе, не подозревая о наличии какого-то там контейнера.
Все красиво и есть прекрасный пример — COM. Но, увы я с уверенностью могу сказать, что в большинстве проектов до выделения компонентов дело просто не доходит... Проекты часто деградируют до крайне высокой стоимости поддержки и их или замораживают или переписывают с нуля. И в этом случае DI (как подход) имхо значительно увеличивает сложность систем на начальном уровне.
IQ>>Собственно ситуация имхо довольно типичная — мне то "опыт подказывает", а молодежь старательно "набивает шишки", но при этом, я почему-то сходу не нашел ни одного внятного объяснения от популяризаторов DI того, почему наивное использование DI будет провальным. Поэтому я решил таки сформулировать свой вариант
V>А как ещё учиться программистам? Только набивать шишки, анализировать свои ошибки, меняться.
В том то и парадокс, что проблемы DI почему-то не анализируют.
IQ>>Посмотрим на типичный пример наивного DI: IQ>>Ребята... вот эта низкоуровневая "требуха" это что ли "сервис"? Вот эти все "внутренности наружу" это инкапсуляция и архитектура? Как получилось, что попытка "соблюсти" принцип DIP очевидно вызывает нарушение всех остальных принципов SOLID и на это закрывают глаза? Как можно внедрять "зависимость сервиса" в ситуации, когда разработчик не способен создать сам внедряемый сервис? Проблема тут имхо базовая — разработчик не имеет навыков создания объектной декомпозиции и пытается компенсировать это использованием сложных механизмов, смысла которых он не понимает.
V>Разработчик рано или поздно избавится от этих кишок наружу — сначала спрячет их за фасадом, изолирует их, а потом ещё как-нибудь разделит — количество зависимостей между компонентами уменьшится. Но это уже мало имеет отношения к механизму внедрения зависимостей.
Т.е. возможно... в финале... разработчик исправит дефекты вызванные нарушением SOLID, спровоцированные наивным использованием DI. Но здесь имхо возникает онтологический разрыв — если разработчик способен понять, что его "наивный DI" был ошибкой, тогда почему он его в таком ошибочно виде внедрил? Т.е. чтобы перейти от наивного DI к компонентной архитектуре, от разработчика требуется имхо крайне серьезный профессиональный рост, а на это нужны годы.
V>Плагины эти сначала надо научится выделять из кишков из примера выше. Сначала контроллер набирает кучу зависимостей, раздувается, потом становится ясно что некий кластер этих зависимостей сам по себе является компонентом, этот компонент отделяется, и контроллер начинает сдуваться — теперь у него всего пара зависимостей и он занимается только тем, чем и должен заниматься — управлять запросами и откликами.
V>Это процесс итеративный, главное не надо думать, что ясная архитектура должна рождаться сразу. Код должен писаться, а потом читаться и правиться. Только после серии правок начнёт вырисоваться внятная схема взаимодействия объектов.
Я это понимаю поэтому даже и не думаю в сторону DI на начальных стадиях проекта, т.к. ничего кроме синтаксического оверхеда это не принесет.
V>Почему это названо проблемой конфигурации (внедрения зависимостей)? Конфигурация и архитектура не одно и то же.
В примере наивного DI который я привел, "внедрение зависимостей" доминирует над всем. И у этого кстати есть забавнейшее следствие — бизнес логика часто "выдавливается" "наивным DI" в клиентские javascript и в хранимые процедуры. Разработчик уже и сам чувствует, что "наивный DI" его ограничивает, но упорно от него не отказывается.
Здравствуйте, LaptevVV, Вы писали:
IQ>>Кстати неплохое название для антипаттерна — Colonoscopy Injection и для всей братии зомбированных шаблонами "наивных архитекторов" — архитект-проктолог. LVV>Перевод гугля совершенно "убойный"... LVV>Колоноскопия Инъекции LVV> LVV>Кстати, давайте уж сразу русское токование...
Шарман... мы с вами интелегентные люди оставим "русское токование" для совещаний и разбора полетов
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, IQuerist, Вы писали:
IQ>>Ребята... вот эта низкоуровневая "требуха" это что ли "сервис"? Вот эти все "внутренности наружу" это инкапсуляция и архитектура?
S>Как мне кажется, этот момент — следствие попытки натянуть "классический" DI на все остальные области.
Да, это и есть "наивный DI". В ограниченном инструменте видят решение.
S>К сожалению, DI в чистом виде абсолютно непригоден для использования в тяжёлом биз-коде. Там от DI требуется не закинуть сервисы и отдать объект, а способ протащить эти сервисы по длиннющей цепочке вызовов, причём состав зависимостей часто заранее неизвестен и определяется в рантайме. Для дотнета обсуждали вот тут
Да... протащить контекст по длиннющей цепочке бизнес решений. Поэтому хорошая декомпозиция там жизненно важна.
S>UPD, P.S. Не стоит налегать на SOLID как на аргумент в спорах. Его к сожалению воспринимают как волшебную палочку, хотя на практике подход "потому что SOLID" работает не лучше, чем самолёт из культа карго. Голову никто не отменял
Так ведь часто использование DI только этим самым SOLID и объясняют. Мол нам позарез надо уменьшить зависимость иначе не по SOLID, иначе опять получится говнокод.
Хм... неплохой мем — внедрение Colonoscopy Injection не влияет на количество говнокода, оно лишь добавляет посторонние предметы
Здравствуйте, IQuerist, Вы писали:
vsb>>Так что вы предлагаете, учитывая, что тестировать надо? Я пока ничего лучше DI не видел.
IQ>Я предлагаю не принимать архитектурные решения в рассчете на "сервисы" (тестирование), которые с крайне высокой долей вероятности никогда не будут реализованы.
Но ведь юнит-тестирование это стандарт-де факто в современном софтостроении. Писать софт без тестов это как пользоваться винраром для контроля версий.
Здравствуйте, vsb, Вы писали:
vsb>Но ведь юнит-тестирование это стандарт-де факто в современном софтостроении. Писать софт без тестов это как пользоваться винраром для контроля версий.
юнит-тестирование это не стандарт, а всего лишь инструмент. Стандартом он никогда не станет, т.к. к нему не применимы критерии оценки.
Здравствуйте, Sinix, Вы писали:
S>Вот да-да-да. На практике DI сам по себе никак не помогает и не упрощает процесс тестирования. Сложный код с полудесятком зависимостей одинаково неприятно покрывать тестами, что с DI, что без. Простой вообще не должен требовать DI для тестов
А как ты предлагаешь подсовывать моки/фейки без DI?
S>+1, только я бы немного по-другому сформулировал. Фраза "я добавил возможность" на уровне архитектуры на самом деле означает "теперь нам всем придётся это использовать". Сам по себе DI экономит кучу времени, но только до момента, когда он не вылезает из своей родной ниши. После этого лучше смотреть в сторону других инструментов.
Что такое "родная ниша" DI?
S>UPD, P.S. Не стоит налегать на SOLID как на аргумент в спорах. Его к сожалению воспринимают как волшебную палочку, хотя на практике подход "потому что SOLID" работает не лучше, чем самолёт из культа карго. Голову никто не отменял
+100500. КМК, его скорее стоит воспринимать как базворд, позволяющий попытаться произвести впечатление на оппонентов.
так все-таки, какая основная мысль вашего поста — что бездумное использование DI — типичная ошибка неумелого архитектора, или, что сам паттерн переоценен?
Здравствуйте, Lexey, Вы писали:
EP>>Например как альтернатива serivce locator. В более общем виде — dynamic scoping. L>Service Locator — это не альтернатива, а вариант реализации DI.
Зависит от определения, это уже терминологический вопрос. Вот например из wiki:
Dependency injection separates the creation of a client's dependencies from the client's behavior, which allows program designs to be loosely coupled[7] and to follow the dependency inversion and single responsibility principles.[4][8] It directly contrasts with the service locator pattern, which allows clients to know about the system they use to find dependencies.
Хотя с другой стороны, чуть ниже там:
The different injector implementations (factories, service locators, and dependency injection containers) are not that different as far as dependency injection is concerned.
Если нам не помогут, то мы тоже никого не пощадим.
