а цикломатичность?

то что говнище написано это одно

это 200 тест кейсов делать?

ну ты теплое с соленым не путай

я думаю эти проблемы связаны, т.е. много зависимостей = проблемы с архитектурой

Перелет 1к, билет 1.5к, гостиница от 300 за ночь.

Это ещё довольно скромный, оптимистичный ценник, и без еды

>т.е. много зависимостей = проблемы с архитектурой или проект сложный

Это ещё довольно скромный, оптимистичный ценник, и без еды

да уж. компании снг такое оплачивают разве?

у меня проект где сделано так как советует Дмитрий, и класс у которого 20 зависимостей и 900 строк кода с 15 публичными методами, и в нем очевидные архитектурные проблемы например смешана логика выборки данных и сохранения, поэтому валидатор живет рядом с динамическим запросом на выборку данных из БД

очевидно, все низкоуровневое с базой в отдельный компоненты-репозитории, валидаторы в компоненты сервисы

и уже потом их отдельно инжектить в 3 сервис

да уж. компании снг такое оплачивают разве?

Не знаю про снг

эт как?

https://twitter.com/DailyKotlin/status/730108468368179201 Вот так + вместо @Service делаешь @Bean в конфигурации

тред не читал, но имхо циклические зависимости это звоночек, что с кодом что-то не так

и вот тут возникает вопрос, будет много зависимостей, как в конструкторе, так и через поля

так в чем прикол?

https://twitter.com/DailyKotlin/status/730108468368179201 Вот так + вместо @Service делаешь @Bean в конфигурации

с @Component тоже работает

с @Component тоже работает

Ессно

дженерик стереотип

дженерик стереотип

Ответ простой: в моем проекте за филд инжекшен сразу по шам полетит подача, поэтому нехер тут спорить

Ответ простой: в моем проекте за филд инжекшен сразу по шам полетит подача, поэтому нехер тут спорить

это к чему?

и вот тут возникает вопрос, будет много зависимостей, как в конструкторе, так и через поля

не факт что их было бы много если бы инжектилось через конструктор, как минимум отсеялись бы циклические связи(сейчас они там есть), просто это слишком просто дописать @Autowired private SomeOtherService someOtherService; и разраб тупо лепил зависимости чтобы не тратить время на обдумывание и рефакторинг

это к чему?

Это к тому что плюсов у филд инжекшен нету, обычно все скатывается в вонючий код

Если организационно не следить

я вообще то про то, что @Component - абстрактный стереотип

к ответу выше

тред не читал, но имхо циклические зависимости это звоночек, что с кодом что-то не так

логика может быть циклическая..

логика может быть циклическая..

Её можно распутать

есть ли статьи на эту тему?

если у тебя два сервиса зависят друг от друга - нужно делать третий сервис

и это правильно

если у тебя два сервиса зависят друг от друга - нужно делать третий сервис

что тоже может быть плохо

т.к. плодятся классы обертки

Причем тут обертки

если у тебя два сервиса зависят друг от друга - нужно делать третий сервис

они могут не друг от друга зависить, а где-то через 5е колено

я прислушался к вам, но хотелось бы конкретный разбор в какой-нибудь статье

они могут не друг от друга зависить, а где-то через 5е колено

Это тоже плохо, не должно так быть

т.к. плодятся классы обертки

А вот это спорно, не будет класа обёртки, будет отдельный сервси со своим функционалом.

И его проще тестировать

И его проще тестировать

убер поинт

http://vojtechruzicka.com/field-dependency-injection-considered-harmful/

я прислушался к вам, но хотелось бы конкретный разбор в какой-нибудь статье

окей

а еще есть?

это первое что нагуглил

а еще есть?

Есть гугл

Если тебе не очевидно что нельзя делать филд инжекшен

Тебе переубедить с филд инжекшином, задача такой же сложности, что и Раслана перевести на скалу.

мне не нравится твоя позиция радикальная Руслан

очевидно

Если ты не видешь проблем, пиши как удобно

это вообще профессионал в споре слово использовать не должен

главное согласуй свои решения с командой

а вообще говорю из опыта(не джавы), если инжектить через сеттеры/филды - тогда нет контроля над тем сколько ты инжектишь и оно не так очевидно если у тебя 10 зависимостей, тебе ничто не мешает добавить еще один сеттер/филд. а если у тебя через конструктор идет, то оно у тебя перед глазами и ты задымываешься перед тем как добавить лишнюю сеттеры/филды можно ж и не вызвать, они необязательные. а конструктор добавляет лишней проверки и не нужно писать в одном классе 10 раз autowired ?

главное согласуй свои решения с командой

вот это очень умное сообщение

и самое главное

а не ААА ОЧЕВИДНО ЮЗАТЬ ДОЛЖЕН МНЕ ТАК СКАЗАЛИ

плюс код должен бабки зарабатывать

по хорошему

а вообще говорю из опыта(не джавы), если инжектить через сеттеры/филды - тогда нет контроля над тем сколько ты инжектишь и оно не так очевидно если у тебя 10 зависимостей, тебе ничто не мешает добавить еще один сеттер/филд. а если у тебя через конструктор идет, то оно у тебя перед глазами и ты задымываешься перед тем как добавить лишнюю сеттеры/филды можно ж и не вызвать, они необязательные. а конструктор добавляет лишней проверки и не нужно писать в одном классе 10 раз autowired ?

да, да, согласен

но я ведь выше писал, что обязательно будут случаи, когда и куча сеттеров и куча филдов в конструкторе

а вообще говорю из опыта(не джавы), если инжектить через сеттеры/филды - тогда нет контроля над тем сколько ты инжектишь и оно не так очевидно если у тебя 10 зависимостей, тебе ничто не мешает добавить еще один сеттер/филд. а если у тебя через конструктор идет, то оно у тебя перед глазами и ты задымываешься перед тем как добавить лишнюю сеттеры/филды можно ж и не вызвать, они необязательные. а конструктор добавляет лишней проверки и не нужно писать в одном классе 10 раз autowired ?

ну, на самом деле, в спринге ты конструкторы тоже руками не вызываешь, только когда тесты пишешь

но я ведь выше писал, что обязательно будут случаи, когда и куча сеттеров и куча филдов в конструкторе

если я открою код где такое есть - он плачевен и идет первый в списке на рефакторинг

ну, на самом деле, в спринге ты конструкторы тоже руками не вызываешь, только когда тесты пишешь

я за тесты и говорю)

если я открою код где такое есть - он плачевен и идет первый в списке на рефакторинг

и решается это декомпозицией, правильно?

если я открою код где такое есть - он плачевен и идет первый в списке на рефакторинг

а часто ты даже контсрукторы можешь не писать AVE LOMBOK

и решается это декомпозицией, правильно?

да, там очевидные области для разделения

да, там очевидные области для разделения

поинт хороший, но так же очень легко скатиться до огромного числа бинов

и это тоже надо держать в голове, если у вас монолит

ERROR: S client not available

поинт хороший, но так же очень легко скатиться до огромного числа бинов

тут соглашусь все же должен быть какой то предел

именно это я и хотел сказать

так что думаю тема теперь закрыта

баланс и работа с командой - всему голова

я просто пишу много юнит тестов, и большие классы сложно тестировать

так что это скорее всего основная причина

кстати, а как зависимости в контроллер внедряешь?

тоже через конструктор?

тоже через конструктор?

да

в спринге да, на симфони через контейнер достаем ?

На самом деле, там всего должен быть один бин, на сервис, в идеале

ну это если не держать логику работы с сессиями или еще бог знает с чем

ну это если не держать логику работы с сессиями или еще бог знает с чем

Это спринг делает неявно

На самом деле, там всего должен быть один бин, на сервис, в идеале

ага и смысл тогда в конструторе ради 1 бина...

если только отдельно рест контроллы тестить

тестирование контроллеров то еще веселье

а я приноровился

тестирование контроллеров то еще веселье

только если у тебя больше чем круд

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

если серверный рендеринг, где обильно юзаются сессии, мультистеп формы и пропихивание данных в js - тот еще адок

ну если серверная шаблонизация

можно и не тестить тогда на сервере

есть автотесты наконец

а вот если есть какое-нибудь API, то было бы полезно

контроллеры же через mockMvc тестируют

кстати, а если вам в тестах нужно заинжектить что-то, вы это тоже через конструктор делаете?

?????

кстати, а если вам в тестах нужно заинжектить что-то, вы это тоже через конструктор делаете?

ну да

ну а тут то какой профит?

а как еще?

ну в тоже поле

ты же не будешь этот тест юзать в другом тесте, число зависимостей у тебя 1-2