Если не секрет, при правильном использовании - какие проблемы может доставить даггер? Разумеется, кроме необходимости создания нескольких дополнительных классов

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

В идеале должны даваться все плюсы DI=)

Тестируемость, изоляция отдельных классов/модулей/компонентов друг от друга

Но к сожалению, в исполнении Dagger все эти преимущества даются в несколько искаженном формате, потому что в принципе сам по себе Android не дает такой власти над инстанцированием классов

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

Но в плане удобства до того же Spring ужасно не дотягивает

Но в плане удобства до того же Spring ужасно не дотягивает

спасибо за ответ.

Да не за что)

В целом я бы хотел указать как раз на то, что тесты нужны крайне небольшому количеству мобильных проектов.

Изоляция тоже условие скорее желательное, чем обязательное. Не вполне понятно, зачем это тащить в мобилку

энтерпрайз пусть живёт своей жизнью, тут вопросов нет

Ну... В домашних проектах - возможно да, в проектах стартапов/соло-разработчиков - может быть тоже. Но в компании, у которой в активе есть хотя бы 5-7 активно поддерживаемых и развиваемых приложений - без этого никуда.

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

Плюс, мало кто заморачивается тем, чтобы корректно держать переиспользуемые инстансы в памяти только в рамках того жизненного цикла, где это нужно. Из-за этого лично я неоднократно видел код, в котором в 5 конструкторах 5 разных классов создается один и тот же инстанс какого-нибудт http-клиента с одними и теми же настройками. И когда возникает необходимость, например, вкорячить в каждый запрос куку - приходится это делать в 5 разных местах.

Ну... В домашних проектах - возможно да, в проектах стартапов/соло-разработчиков - может быть тоже. Но в компании, у которой в активе есть хотя бы 5-7 активно поддерживаемых и развиваемых приложений - без этого никуда.

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

Плюс, мало кто заморачивается тем, чтобы корректно держать переиспользуемые инстансы в памяти только в рамках того жизненного цикла, где это нужно. Из-за этого лично я неоднократно видел код, в котором в 5 конструкторах 5 разных классов создается один и тот же инстанс какого-нибудт http-клиента с одними и теми же настройками. И когда возникает необходимость, например, вкорячить в каждый запрос куку - приходится это делать в 5 разных местах.

Если у кого-то кривые лапы, которыми он треды стартует где не надо, да ещё и 5-7 раз - это не даггер нужен, а увесистые, от всей души, пиздюли)

но это другая история

у меня сегодня горит

Согласен :)

Ситуацию рукожопов можно обсуждать бесконечно, им дай фреймворк или либу с единственным методом sdelatZaebis(), и они все равно что-нибудь сделают не так)

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

Казалось бы, да

Но на деле лапша никуда не исчезает

Появились переменные, появилась лапша с ними

Функции -- теперь они образуют лапшу

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

Ооо, это уже разговор совсем о другом, как мне кажется)

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

Мы просто переносим её на другой уровень абстракции

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

И не только функции

Короче, вся лапша от нас самих

Ну и от апи, который к ней принуждает

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

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

А откуда она там взялась - я знать, условно говоря, не хочу

Мы все хотим так :)

Просто тут мне, как это часто бывает, бьют по рукам даггер вместе с андроидом и приходится писать уродские конструкции типа WTFComponent.inject(this)

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

Вот тебе и лапшеобразная зависимость :)

Вот одна из причин, почему мне нравится Rx=)

Он в какой-то мере принуждает писать stateless-код)

Там точно такая же абстракция наверх :)

Но в целом да, функциональное программирование поустойчивее будет

К сожалению, на Андроиде можно писать только либо быстрый, либо правильный код :)

Я все жду, когда же уже наконец кто-нибудь посчитает в процентах, какое же влияние rx оказывает на футпринт приложения :)

А как ты собираешься считать GC?

Можно посчитать только время выполнения кода

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

Которое у Рх будет меньше, кстати

Ну логи и все.

Да банально на уровне того, сколько памяти потребуется на выполнение какой-то сложной цепочки вычислений над одним и тем же набором данных без rx и c ним)

Будешь их парсить? :)

Тут дело не в объеме памяти, а в размере графа

Объем памяти влияет на частоту GC

Количество объектов на время его работы

Я не знаток в кишках rx, но насколько я могу понять - каждый оператор в цепочке вычислений observable должен порождать новые данные

Т.е. банально, был у меня лист int'ов, я его через rx смапил на лист float, а потом на стринги. Если я все себе правильно представляю, у меня в памяти будут держаться все три листа, пока я не ушатаю этот observable

Новые данные, сам оператор функтор, все объекты вроде обсервера и сабскайбкра тоже

И оьсерваблы

И листов из инттв нет

Вот об этом я и говорил) На словах вроде все понятно, но интересно было бы оценить реальное воздействие

Есть из интегеров

Блин, да это все понятно, тут не школьники вроде сидят)

Ты удивишься, сколько разрабов об этом не знает :)

И думает, что так типа тоже норм

Так что прости, если объяснял очевидное :)

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

ERROR: S client not available

Все норм)

Однажды пришел чувак 32-35 лет от роду и не смог объяснить, что такое интерфейс, а что такое - абстрактный класс

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

¯\_(ツ)_/¯

Однажды пришел чувак 32-35 лет от роду и не смог объяснить, что такое интерфейс, а что такое - абстрактный класс

ну и норм. Ситуация Виталия ещё хуже

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

хотя с другой стороны от задания зависит..

ну, кстати, есть же библиотека Trove с коллекциями из примитивов

Однажды пришел чувак 32-35 лет от роду и не смог объяснить, что такое интерфейс, а что такое - абстрактный класс

тут по-разному можно объяснить я встречал и "интерфейс - это свойство объекта, абстрактный класс - сущность"

Да мне бы как угодно сошло, там человек вообще таких слов не знал)

Имхо, надо идти от самого простого. В интерфейсе не может быть реализованных методов, а в абстрактном классе могут быть)

Ну а дальше уже можно начинать философствовать на тему того, когда и что нужно юзать)

тут по-разному можно объяснить я встречал и "интерфейс - это свойство объекта, абстрактный класс - сущность"

Интерфейс, по-хорошему — множество публичных методов класса.

Имхо, надо идти от самого простого. В интерфейсе не может быть реализованных методов, а в абстрактном классе могут быть)

а как же default методы?

Это уже java 8 и ее извраты)

ой, точно, андроид, да

Ну с дефолтом получается, что интерфейсы это просто трейты

Для множественного наследования

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

Ага

Поэтому и "по-хорошему"

Короче, думаю мы тут все друг друга хорошо понимаем) Вот если б тот чувак так же со мной поговорил - я бы остался доволен.

Но нет, он сказал что-то вроде "м...ээээээ....нуууу"

Это был оффер? :)

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

Нет, это был контроффер

Или я даже не знаю как назвать ситуацию, когда я был готов заплатить, лишь бы он ушел :)

:(

Я о себе

Ааа

Неее, у нас, к сожалению, есть формальная процедура)

Нужно прийти и сказать все то же самое в лицо :)