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

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

IQ>·>У меня был опыт с такими конструкторами. Рекорд толи 37 толи 47 параметров было, я не помню. И знаешь — это был вариант лучше остальных мною виденных. Была уверенность — если что-то не так сделаю — код просто не сможет скомпилиться, а не грохнется в проде ВНЕЗАПНО.
IQ>Совсем не понятно откуда такая уверенность.
Из моего опыта, я повидал и Spring разных версий, и Guice, и JBoss Seam, и доморощенный код на всяких синглтонах и прочих контекстах, и чисто java код, где даже большинство стандартных JDK-классов (типа String) не используется, и даже, прости господи, EJB. Так вот самый дубовый и простой в написании и поддержке код это именно DI+CI с явно выделенным composition root. К сожалению, делать просто — сложно, а делать сложно — просто.

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

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

IQ>>>PS и вот еще какая проблема — каждому "сервису" надо дать имя. И если методу еще как-то что-то можно вымучить исходя из его поведения. То с сервисами все обстоит гораздо хуже. Имена дают нелогичные, непонятные и ошибочные, камменты быстро деградируют и чтобы узнать о том, что же таки эта зависимость делает приходится лезть в ее реализацию,
IQ>·>Вот уж это совсем не проблема. Рефакторинг rename method/class — занимает около 1 минуты, включая коммит+пуш.
IQ>Шпасиба друг! А я и не знал, что "Рефакторинг rename method/class" поможет придумать грамотные, понятные и верные названия для сервисов.
Конечно помогает. Как только придумаешь — зафиксируешь это в коде. Если не придумаешь сразу — придумай хоть что-нибудь и запиши как кажется на текущий момент, отливать в граните ничего не надо.