Это не только со знаниями, с деньгами также

С разными негативными вещами тоже

еее карма

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

да ну, конфы херня для эйчаров, чтобы всякие гнусные и ассоциальные программисты повылазили из своих нор =)

Как развлечение между серьезными докладами - идеально

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

Вот, ты мне сразу понравился

бюджет примерно $5000 чтоб скромно съезить. Так что да, без сомнений на такие деньги можно очень хорошо покутить

а че так много выходит?

а че так много выходит?

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

не дешевые билеты

Всё так

что вы думаете об autowire на больших проектах? нормально ли такое поддерживать?

что вы думаете об autowire на больших проектах? нормально ли такое поддерживать?

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

что вы думаете об autowire на больших проектах? нормально ли такое поддерживать?

конкретней давай

речь о Scala фреймворке?

у меня пока был опыт, что бывает, когда бинов ОЧЕНЬ много

не, java/spring

конкретных примеров нет, но не раз натыкался на статью что сложнее поддерживать чем xml

конкретных примеров нет, но не раз натыкался на статью что сложнее поддерживать чем xml

Хуйня

типа implicit и все такое

главное не писать @Autowired на полях, а инжектить через конструкторы

главное не писать @Autowired на полях, а инжектить через конструкторы

ну эт само собой

Хуйня

+++

главное не писать @Autowired на полях, а инжектить через конструкторы

тоже хуйня

нет это не хуйня

если в официальных доках инжектят в филды и ничего

главное не писать @Autowired на полях, а инжектить через конструкторы

ну это на самом деле спорно, я сам стараюсь так делать, тем более можно уже и не писать @autowired

если речь про тесты - есть мокито и инжект мокс

единственная проблема с автовайред - он самый медленный из инжектов

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

если в официальных доках инжектят в филды и ничего

Спринг уже 100 раз сказал что это ошибка, костыль, чтобы разрешить создание циклических бинов)

потому что спринг тупой и просто по имени перебирает всю мапу с бинами

Спринг уже 100 раз сказал что это ошибка, костыль, чтобы разрешить создание циклических бинов)

это костыль который склоняет тебя к циклическим зависимостям

как раз

если в официальных доках инжектят в филды и ничего

если можно заинжектить весь контекст, это ж не значит что это нужно делать

при инжекте через конструктор такого не будет, к тому же нет желания все запихнуть в один класс через @Autowired это же изи

написал 20 @Autowired кайф

да и идея в последних версиях уже на эту тему начинает задалбывать что "не надо так делать!"

так а конкретно какие проблемы?

т.е я так понял тут уже никто не описывает контейнер в xml?)

т.е я так понял тут уже никто не описывает контейнер в xml?)

уже давно, бывают исключения только при интеграциях

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

xml это вообще ужас, у многих просто ненависть к этому формату

так а конкретно какие проблемы?

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

т.е я так понял тут уже никто не описывает контейнер в xml?)

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

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

это все пук в воздух

xml это вообще ужас, у многих просто ненависть к этому формату

yml не лучше

конкретные проблемы

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

конкретные проблемы

в final поле можно делать автовайринг?

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

так их не должно быть, максимум 3-4

если их куча - значит что-то пошло не так ведь?

так их не должно быть, максимум 3-4

SRP во все поля ?

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

В котлине конструкторы выглядят очень няшно ;)

больше одно — реджектишь коммит

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

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

поэтому есть желание выпилить зависимости из класса

ну бывает такая бизнес-задача

что куча зависимостей

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

ну да

Зато насрать в один бин 10-20 зависимостей через филды - само то

но ведь вы тогда замедляете старт приложения

ERROR: S client not available

Зато насрать в один бин 10-20 зависимостей через филды - само то

поверь насрать - это создавать бин на каждый чих

но ведь вы тогда замедляете старт приложения

Охереть, т.е. ты из-за фреймворка будешь костылить в своем коде?

но ведь вы тогда замедляете старт приложения

а кому-то сейчас не класть на это?

прям долго стартует?

Охереть, т.е. ты из-за фреймворка будешь костылить в своем коде?

нет, почему костылить

я аргументов не увидел

кроме того, что вы слышали, что так рекомендуют

Лол, ты не слушаешь

а в реальных задачах немного все по-другому

В котлине конструкторы выглядят очень няшно ;)

это чтоли слушать?)

т.е я так понял тут уже никто не описывает контейнер в xml?)

Лет восемь как

прям долго стартует?

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

хотя во многих местах можно было статикой обойтись

я аргументов не увидел

нарушение SRP большая вероятность, плюс поддерживать такое довольно сложно у меня вот щас открыт класс, в нем 6 зависимостей и при этом только 1 публичный метод на 60 строк. щас вот надо еще 1 зависимость пропихнуть и как-то рука не поднимается...

Вот тебе список: 1. Тестирование: тебе не нужны специальные аннотации, ты просто создаешь объект и тестируешь. 2. Качество кода: много бинов в конструкторе заставит тебя задуматься о качестве твоего кода. 3. Циклические зависимости: заставляет распутывать твою архитектуру Уже после первого пункта можно заканчивать разговор, и соглашаться что конструктор инжекшен лучше

Лет восемь как

?

нарушение SRP большая вероятность, плюс поддерживать такое довольно сложно у меня вот щас открыт класс, в нем 6 зависимостей и при этом только 1 публичный метод на 60 строк. щас вот надо еще 1 зависимость пропихнуть и как-то рука не поднимается...

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

4. С spring 4.3 твой бин вообще отвязан от спринга, если ты используешь constructor injection

а чем плох ДИ в конструкторе?

4. С spring 4.3 твой бин вообще отвязан от спринга, если ты используешь constructor injection

эт как?

максимально explicit

то что написал @Component и не нужно делать @Autowired?

а чем плох ДИ в конструкторе?

В джаве плох тем что бойлерплейт

да ну, конфы херня для эйчаров, чтобы всякие гнусные и ассоциальные программисты повылазили из своих нор =)

Асоциальные программисты не вылазят из своих нор ради каких то конференций

В джаве плох тем что бойлерплейт

ну такое, бойлерплейта бояться -- на джаве не писать

1. Тестирование = это спорный момент, в библиотеке мохито все из коробки 2. Если много бинов в конструкторе и такова бизнес задача, то чем это лучше много зависимостей в классе через филды 3. У меня нет циклических зависимостей от слова совсем

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

я не говорю, что инжект через сеттер или конструктор плохо

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

мне сложно представить как выглядит тест на сервис с 20 зависимостями

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

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