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

IQ>·>Плодить интерфейсы можно и без DI. То что их плодят выкрикивая "DI!" — виновато лишь невежество, а не DI. Бороться надо с невежеством, а не с DI.
IQ>Не спорю, DI всего лишь еще один важный повод.
Повод для чего?

IQ>·>Из моего опыта, я повидал и Spring разных версий, и Guice, и JBoss Seam, и доморощенный код на всяких синглтонах и прочих контекстах, и чисто java код, где даже большинство стандартных JDK-классов (типа String) не используется, и даже, прости господи, EJB. Так вот самый дубовый и простой в написании и поддержке код это именно DI+CI с явно выделенным composition root. К сожалению, делать просто — сложно, а делать сложно — просто.
IQ>))) пост не о том, где DI хорош (кстати это имхо был бы крайне полезный пост), а о том, где он плох.
Как выяснилось нигде он не плох. Плохи бывают IoC-контейнеры. Вот даже у тебя ambient context — это тот же DI, но один из плохих его видов реализации.

IQ>>>·>Написано же в книге, что сам по себе такой конструктор проблем не создаёт, просто страдает эстетика, но код всё равно относительно легко контролируется и понимается.
IQ>>>Ох... ну раз в книге написано, значит г..нопроектов откуда я отхреначивал наивный DI не было, может они мне приснились...
IQ>·>По-моему опыту так же. Что такое "отхреначивать наивный DI" ты так и не прояснил. Как я понял — ты заменял CI на глобальные переменные.
IQ>Ага на 2-3 глобальных сервиса. Ну глобальные они только формально, на самом деле они в local context, как собственно и сервисы DI.
Изменяемые данные в статических полях есть? Значит глобальные и формально, и на самом деле.
В продуманной архитектуре зависимостей нет контекста, есть composition root.

IQ>·>В чём именно было улучшение-то от этого твоего отхреначивания?
IQ>Хелперы стали хелперами без паутины зависимостей, которая в рамках конкретно этих проектов была излишняя.
Хелпер вообще-то антипаттерн практически, не понимаю почему ты этим хвастаешься. Это индикация, что ты толком не понимаешь что данный класс делает, ну и называешь его хелпер. Вот вспомним об SRP. Какая обязанность у хелпера?

IQ>Ну и количество интерфейсов уменьшилось на 90%
Десятый раз повторяю, что интерфейсы для DI+CI не нужны, да и рефакторинг тривиален. Ты их мог и так уменьшить, сохраняя управляемость зависимостей.

IQ>>>Вот эти вынужденные фасады над фасадами над фасадами это "понимаемо" и "легко изменяемо"?
IQ>·>Что значит вынужденные? Если они вынуждены, то дело не в CI, а с твоими любимыми глобальными переменными получится амбиентные синглтоны провайдеров фабрики синглтонов контекстов.
IQ>Вы же сами ссылку на главу "6.4. Обсуждение феномена Constructor Over-injection" давали. Вы текст не читали что ли? Марк Симан по эстетическим причинам разговор про "Рефакторинг по направлению к Фасадным сервисам" завел?
Ты похоже вообще не читал, почитай, таки да, по эстетическим:

Тем не менее, некоторым людям неудобно, если число зависимостей растет. Они не любят конструкторы со слишком большим числом параметров.

Мало того, что DI+CI тут не причём, т.к.

Этот плохо пахнущий код не появляется, но усугубляется в результате использования DI

Вместо того чтобы чувствовать неловкость из-за Constructor Over-injection, мы должны принять его как удачный побочный эффект внедрения в конструктор. Это сигнал, который предупреждает нас всякий раз, когда класс берет на себя слишком большую ответственность.