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

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

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

IQ>>Может это дело потенциально полезное, но имхо мало кто будет этим заниматься на всех давят сроки, поэтому будут оставаться конструкторы с 20-30 параметрами на все случаи жизни.
·>У меня был опыт с такими конструкторами. Рекорд толи 37 толи 47 параметров было, я не помню. И знаешь — это был вариант лучше остальных мною виденных. Была уверенность — если что-то не так сделаю — код просто не сможет скомпилиться, а не грохнется в проде ВНЕЗАПНО.

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

IQ>>А когда на подходе дед-лайн новые классы будут создаваться копи-пастом вообще всех зависимостей самого жирного конструктора. И это в лучшем случае, в худшем максимальное количество данных будут передавать например на клиента в javascript чтобы допилить бизнес логику там. Т.к. там можно избежать всей этой возни с зависимостями и интерфейсами.
IQ>>Да... метод наименьшего сопротивления.
·>Написано же в книге, что сам по себе такой конструктор проблем не создаёт, просто страдает эстетика, но код всё равно относительно легко контролируется и понимается.

Ох... ну раз в книге написано, значит г..нопроектов откуда я отхреначивал наивный DI не было, может они мне приснились...

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

Вот эти вынужденные фасады над фасадами над фасадами это "понимаемо" и "легко изменяемо"?

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

Шпасиба друг! А я и не знал, что "Рефакторинг rename method/class" поможет придумать грамотные, понятные и верные названия для сервисов.

IQ>>а искать ее приходится как правило по интерфейсу.
·>Открой для себя рефакторинг inline interface.

·>Ты считаешь это проблемой потому что у тебя плохое качество кода и абсолютно любое его изменение — страшно, ты не понимаешь что где может поломаться. Это звоночек.

Лично у меня, я считаю, приемлемое качество кода, потому что бизнес логика моих систем активно расширяется многие годы без рисков того, что проект деградирует настолько, что единственным верным решением будет — переписать его с нуля. Это обеспечивается всего лишь грамотной декомпозицией.