Здравствуйте, ·, Вы писали:
·>Здравствуйте, 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.
·>Изменяемые данные в статических полях есть? Значит глобальные и формально, и на самом деле.
В статических полях исключительно stateless сервисы. Изменяемые данные в local context. Это или thread contect или httpcontext.
·>В продуманной архитектуре зависимостей нет контекста, есть composition root.
Вы думаете local context такой стойкий потому что разработчики ленивые? local context такой стойкий потому, что в него отлично ложатся контексты бизнес операций.
IQ>>·>В чём именно было улучшение-то от этого твоего отхреначивания?
IQ>>Хелперы стали хелперами без паутины зависимостей, которая в рамках конкретно этих проектов была излишняя.
·>Хелпер вообще-то антипаттерн практически, не понимаю почему ты этим хвастаешься.
Я не хвастаюсь. Просто раньше из этих хелперов состояли DI сервисы.
·>Это индикация, что ты толком не понимаешь что данный класс делает, ну и называешь его хелпер. Вот вспомним об SRP. Какая обязанность у хелпера?
Обязанность хелпера — быть помойкой хелперных методов
IQ>>Ну и количество интерфейсов уменьшилось на 90%
·>Десятый раз повторяю, что интерфейсы для DI+CI не нужны, да и рефакторинг тривиален. Ты их мог и так уменьшить, сохраняя управляемость зависимостей.
Я тут запоздало сообразил, что не видел вашего варианта DI. Варианты с DI фреймворками понятны. Я глянул ваши ответы и не смог найти механизм, который будет в вашем случае создавать и хранить сервисы и инжектить их в клиенты.
IQ>>>>Вот эти вынужденные фасады над фасадами над фасадами это "понимаемо" и "легко изменяемо"?
IQ>>·>Что значит вынужденные? Если они вынуждены, то дело не в CI, а с твоими любимыми глобальными переменными получится амбиентные синглтоны провайдеров фабрики синглтонов контекстов.
IQ>>Вы же сами ссылку на главу "6.4. Обсуждение феномена Constructor Over-injection" давали. Вы текст не читали что ли? Марк Симан по эстетическим причинам разговор про "Рефакторинг по направлению к Фасадным сервисам" завел?
·>Ты похоже вообще не читал, почитай, таки да, по эстетическим:
·>Тем не менее, некоторым людям неудобно, если число зависимостей растет. Они не любят конструкторы со слишком большим числом параметров.
·>Мало того, что DI+CI тут не причём, т.к.
·>Этот плохо пахнущий код не появляется, но усугубляется в результате использования DI
·>Вместо того чтобы чувствовать неловкость из-за Constructor Over-injection, мы должны принять его как удачный побочный эффект внедрения в конструктор. Это сигнал, который предупреждает нас всякий раз, когда класс берет на себя слишком большую ответственность.
Ладно, оставим это все на совести адептов DI. Собсна цель моего поста не в том, чтобы запрещать им ковырять в носу.
