Re[15]: О "наивном" DI и об архитектурном бессилии
От: IQuerist Мухосранск  
Дата: 30.09.16 07:53
Оценка:
Здравствуйте, ·, Вы писали:

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

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

Не спорю, DI всего лишь еще один важный повод.

IQ>>Совсем не понятно откуда такая уверенность.

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

))) пост не о том, где DI хорош (кстати это имхо был бы крайне полезный пост), а о том, где он плох.

IQ>>·>Написано же в книге, что сам по себе такой конструктор проблем не создаёт, просто страдает эстетика, но код всё равно относительно легко контролируется и понимается.

IQ>>Ох... ну раз в книге написано, значит г..нопроектов откуда я отхреначивал наивный DI не было, может они мне приснились...
·>По-моему опыту так же. Что такое "отхреначивать наивный DI" ты так и не прояснил. Как я понял — ты заменял CI на глобальные переменные.

Ага на 2-3 глобальных сервиса. Ну глобальные они только формально, на самом деле они в local context, как собственно и сервисы DI.

·>В чём именно было улучшение-то от этого твоего отхреначивания?


Хелперы стали хелперами без паутины зависимостей, которая в рамках конкретно этих проектов была излишняя. Ну и количество интерфейсов уменьшилось на 90%

IQ>>>>Идеи то вроде бы и правильные, а вот их воплощение имхо абсолютно негодное.

IQ>>·>Воплощение должно быть таким, чтобы код был всё ещё понимаемым и легко при желании изменяемым. Явные зависимости этому делу хорошо способствуют.
IQ>>Вот эти вынужденные фасады над фасадами над фасадами это "понимаемо" и "легко изменяемо"?
·>Что значит вынужденные? Если они вынуждены, то дело не в CI, а с твоими любимыми глобальными переменными получится амбиентные синглтоны провайдеров фабрики синглтонов контекстов.

Вы же сами ссылку на главу "6.4. Обсуждение феномена Constructor Over-injection" давали. Вы текст не читали что ли? Марк Симан по эстетическим причинам разговор про "Рефакторинг по направлению к Фасадным сервисам" завел?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.