Полностью с тобой согласен. Я тоже бы никогда не написал подобный код в приложении.
Но эта статья статья вдохновлена как раз именно таким багом который я недавно фиксил в новом проекте. Меня лично больше всего удивило то что вот такими неявными контрактами можно зациклить рекомпозицию. И самое интересное что экран будучи зациклинным вполне нормально себя вел и никак не выдавал потенциальные проблемы перфоманса.
Собственно в статье я хотел поделиться своим кейсом и рассказать что бывает и такое, а хорошие/правильныеПодходы/бестПрактис это уже другая тема.
Я просто тогда не очень понимаю ценность этой публикации. Тут буквально следущее:
Автор утверждает что он преисполнился в чтении книг и хейтит всех инакомыслящих;
Имплементации UseCase должны иметь в названии постфикс Interactor а не UseCase.
Мне кажется в масштабах интерпрайз проектов это на столько не значительная проблема что о говорить о ней както не ловко чтоли. Я надеюсь, что это просто остается вашими мыслями, и вы в погоне за следованим буков книг из 90х у не превращаете ревью пуллреквестов и собеседования в душный стресс-тест.
Спасибо за статью! Мне очень понравилось. Отличные ловушки и хорошо расписаны.
Но не сочтите за глупость но, у меня есть вопрос который сильно уходит в сторону от темы. Мне всегда было интересно как мне, как читателю, работать с подобными статьями? Подобного материала я уже прочитал некоторое количество раз, но все еще нахожу себя в этих ловушках. Поделитесь мнением как должен быть выстроен процесс чтобы они активнее влияли на жизнь? Может вы както сохраняете подобное и перечитываете время от времени или чтото типа того...
Спасибо за статью, очень интересно! Ваше приложение оч быстро запускается, в отличии от МосМетро, и на мой взгляд чуточку быстрее яндекса, это несомненно плюс. Так же хотел бы вам предложить идею: если на станции куда мне надо ехать есть пересадочные станции, то мне бы хотелось не строить маршрут до каждой станции отдельно, а выбрать все вместе (вроде Курская/Курская/Чкаловская) и чтоб отобразился оптимальный маршрут до этого узла. Спасибо
Мне статья показалась очень полезной. Автору спасибо! Интересно было бы еще почитать за остальные принципы SOLID. Единственное, у меня остался такой вопрос: если условно научить выпивоху по разному реагировать на напиток который ему необходимо выпить (стопку водки, или кружку пива), то есть действие «выпить залпом» / «выпить в течении времени». Вот это условие определяющее дальнейшее поведение должно находиться в декораторе или же правильнее вынести это разделение в непосредственно класс который овечат за потребление напитка? На мой взгяд этим должен заниматься декоратор, что вы думаете на этот счет?
Полностью согласен про data-class. В статье показываю какие последствия могут быть из-за таких решений.
Полностью с тобой согласен. Я тоже бы никогда не написал подобный код в приложении.
Но эта статья статья вдохновлена как раз именно таким багом который я недавно фиксил в новом проекте. Меня лично больше всего удивило то что вот такими неявными контрактами можно зациклить рекомпозицию. И самое интересное что экран будучи зациклинным вполне нормально себя вел и никак не выдавал потенциальные проблемы перфоманса.
Собственно в статье я хотел поделиться своим кейсом и рассказать что бывает и такое, а хорошие/правильныеПодходы/бестПрактис это уже другая тема.
Интересно. Может от версии компоуза зависит? Можно тебя попросить залить код на гитхаб чтобы самому поковырять? Было бы интересно разобраться
Я просто тогда не очень понимаю ценность этой публикации. Тут буквально следущее:
Автор утверждает что он преисполнился в чтении книг и хейтит всех инакомыслящих;
Имплементации UseCase должны иметь в названии постфикс Interactor а не UseCase.
Мне кажется в масштабах интерпрайз проектов это на столько не значительная проблема что о говорить о ней както не ловко чтоли. Я надеюсь, что это просто остается вашими мыслями, и вы в погоне за следованим буков книг из 90х у не превращаете ревью пуллреквестов и собеседования в душный стресс-тест.
а где в примере про обработку ошибок?
Спасибо за статью! Мне очень понравилось. Отличные ловушки и хорошо расписаны.
Но не сочтите за глупость но, у меня есть вопрос который сильно уходит в сторону от темы. Мне всегда было интересно как мне, как читателю, работать с подобными статьями? Подобного материала я уже прочитал некоторое количество раз, но все еще нахожу себя в этих ловушках. Поделитесь мнением как должен быть выстроен процесс чтобы они активнее влияли на жизнь? Может вы както сохраняете подобное и перечитываете время от времени или чтото типа того...
> Если проводить аналогию с Kotlin, то это fun completable() из мира
RxKotlin.