Autowired — это зло.

пока я понимаю - вы против Di

В том числе да. Это один из доводов. Вы просили меньше эмоций, больше конкретики. Это - начало

Впереди - больше

Autowired — это зло.

но в современном спринге не используют Autowired

А что используют?

пишут обычный человеческий конструктор

но в современном спринге не используют Autowired

уффффф

но в современном спринге не используют Autowired

от того, что его не пишут не значит, что его нет.

Ну то есь - с моими доводами пока согласен? По поводу того что autowired херит SOLID?

Можно конфиг-класс сделать и там объявить какой инстанс нужно инжектить в овнера

пишут обычный человеческий конструктор

А вызывает его кто?

нет

Поэтому вопрос критичен для дальнейшей дискуссии - почему не согласны?

от того, что его не пишут не значит, что его нет.

именно это и значит

А вызывает его кто?

по-разному. где-то и руками

именно это и значит

Думаешь, магия случается и параметры передаются сами?

Не особо понимаю эту дискуссию. Писать конструкторы и вызывать руками - бойлерплейт. @Autowired рулит.

Instance контроллера кто создает?

Думаешь, магия случается и параметры передаются сами?

думаю, что магии нет и все прозрачно и очевидно

Не особо понимаю эту дискуссию. Писать конструкторы и вызывать руками - бойлерплейт. @Autowired рулит.

бойлерплейт можно не писать, если есть ломбок

А чо там в ломбоке для DI есть?

А чо там в ломбоке для DI есть?

в ломбоке есть генерация конструктора

выкинь спринг и просто как передашь конкретную зависимость?

И вопрос вдогонку - вам знаком такой термин как "Зона Боли" (Zone of pain)? Этот термин критичен в понимании почему спринг и DI контейнеры - говно, а композиция объектов - рулит.

@dmsol может хватит? вы не договоритесь

@dmsol может хватит? вы не договоритесь

Мы не договариваемся. Ктото хотел конструктива - получите, распишитесь

https://www.projectsmart.co.uk/white-papers/chaos-report.pdf

Не понимаю причем тут качество разработки. Мир растет, растут количество IT проектов. Какие-то успешные, какие-то нет. Спринг тут точно не виноват. Скорей дело в неправильных процессах или изначально неверной бизнес-идеи. И вообще, отчет 2014 года...

Не понимаю причем тут качество разработки. Мир растет, растут количество IT проектов. Какие-то успешные, какие-то нет. Спринг тут точно не виноват. Скорей дело в неправильных процессах или изначально неверной бизнес-идеи. И вообще, отчет 2014 года...

Там в процентах)

@dmsol может хватит? вы не договоритесь

я вернулся

Не особо понимаю эту дискуссию. Писать конструкторы и вызывать руками - бойлерплейт. @Autowired рулит.

По моему спринг конфиги стали тем самым бойлер плейтом. Частенько ловлю себя на том, что ковыряю конфиг вместо написания логики.

Точно спринг не виноват?) Есть пруф этой мысли?

Поэтому вопрос критичен для дальнейшей дискуссии - почему не согласны?

вы против IoC, его реализации DI и против ОБЫЧНЫХ конструкторов

конструктива не будет

Спринг стандарт. Можно легко менять/искать разработчиков. Декораторы - не стандарт. Тяжело подобрать людей как раз в «новом ООП»

Спринг стандарт. Можно легко менять/искать разработчиков. Декораторы - не стандарт. Тяжело подобрать людей как раз в «новом ООП»

Да, целиком согласен.

Но этот стандарт создан по глупости.

В основном для кодеров, которые не думают.

Но которых очень много.

Кодеры впринципе не думают

На то и кодер

Им нужен инструмент быстрой сборки приложений, состоящих из сотен форм, контроллеров и прочего.

вы против IoC, его реализации DI и против ОБЫЧНЫХ конструкторов

IoC и конструкторы - добро. DI контейнер вносит сложность.

вы против IoC, его реализации DI и против ОБЫЧНЫХ конструкторов

Пока это контраргументы DI контейнерам. Это еще даже не спринг. Против конструкторов и IoC я ничего не имею.

И их реально миллионы.

Пока это контраргументы DI контейнерам. Это еще даже не спринг. Против конструкторов и IoC я ничего не имею.

так в спринге такие же конструкторы

просто собирает за вас его спринг

Их научить думать сложно. А вот кодить на спринге — легче.

вы этого не поняли еще?

В основном для кодеров, которые не думают.

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

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

НЕТ! ПИШУТ АННОТАЦИИ 24/7

Их научить думать сложно. А вот кодить на спринге — легче.

А спринг тут при чем?)

А спринг тут при чем?)

В спринге понимать что такое ООП не нужно

В спринге понимать что такое ООП не нужно

ооп переоценено

Вообще понимать не нужно почти ничего. Нужно делать по инструкции

Вообще понимать не нужно почти ничего. Нужно делать по инструкции

Егор

Собирать воедино некие магические блоки

И запускать

а где эта инструкция?

просто собирает за вас его спринг

Вранье. Спринг ничего вам не соберет пока вы не сделаете одно из двух: либо проставите конкретные типы/имена/квалифаеры автовиред зависимостям, либо не запилите бессмысленный XML дескриптор на 100500 строк

вот бы под конкретный проект была

Вообще понимать не нужно почти ничего. Нужно делать по инструкции

это идеально, учитывая ту идею, что ты писал выше: "легко заменить одного программиста другим"

нахожу противоречие

Собирать воедино некие магические блоки

Магии там нет. А есть нежелания разбираться как это работает

Вранье. Спринг ничего вам не соберет пока вы не сделаете одно из двух: либо проставите конкретные типы/имена/квалифаеры автовиред зависимостям, либо не запилите бессмысленный XML дескриптор на 100500 строк

это не так

это не так

Что не так

Вообще понимать не нужно почти ничего. Нужно делать по инструкции

На чем быстрее писать: на спринге или на "правильном ООП"?

ERROR: S client not available

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

На чем быстрее писать: на спринге или на "правильном ООП"?

Вопрос в простоте поддержки и скорости внесения новых фич.

вы просто не разобрались

не осилили...

Изначальная скорость разработки не так существенна

Вопрос в простоте поддержки и скорости внесения новых фич.

Это входит в мой вопрос, да

если уж спринг не могут осилить

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

Ну ок, стереотипы. И что? Это типа не каплинг?

куда катится наш рынок?

Вранье

Что не так

Класс помеченный @Configuration устроит?

ппц

дно пробито

скоро эррэй лист создать не смогут

судить о спринге по 3 версии спринга в 2018 - сильно

Это входит в мой вопрос, да

Ну вот SOLID на этот вопрос даёт ответ. Spring частенько ему противоречит. Соотвественно стоимость внедрения новых фич дороже и искать баги приходится в среднем дольше.

судить о спринге по 3 версии спринга в 2018 - сильно

неосиляторы

либо работают над легаси в говнокомандах

Да вы дурни даже аргументацию не дослушали, уже галдите "дно пробито". И еще конструктива хотите?

Да какой нахер с вами конструктив

Давай

Да вы дурни даже аргументацию не дослушали, уже галдите "дно пробито". И еще конструктива хотите?

так зачем ее дослушивать, если ты начал и уже ошибся

так зачем ее дослушивать, если ты начал и уже ошибся

Ну так и где я ошибся

Обычно проблема не в спринге/«декораторах Егора», а в менеджменте, который не понимает ценность здоровых процессов разработки. А аутисты-программисты не могут дать отпор. У Боба Мартина хорошая книга на тему софт скиллов. Каким надо быть профессиональным программистом

Clean Coder

Ну так и где я ошибся

ты не знаешь спринг

а что-то доказываешь

плаваешь

какой-то хмл

в 2018

Класс Configutation - это тот самый бойлерплейт в котором спрятаны new