L2
Тут гибкость очень хорошая нужна. Хорошо манипулировать тем, что знаешь. Мне кажется, такое только с опытом возможно
Size: a a a
2021 June 17
L2
Даже в ООП еще не все противоречия решены
JF
это все дело вкуса. Выберите, что больше нравится и почему. И делайте так. Мне тоже предъявляют за
a :A в котлине. Но мне нравитсяJF
например?
A
а что значит запроксировать?
A
В данном случае - передать флоу эвентов от репозитория как он есть, без доп логики, юзкейс в таком виде будет типичным прокси
https://en.wikipedia.org/wiki/Proxy_pattern
https://en.wikipedia.org/wiki/Proxy_pattern
2021 June 18
N
Всем привет!
JF
Вам туда @android_ru
N
а что тут?
JF
архитектура
N
Спасибо
DK
Орнул с диалога выше
Y
Все верно. Архитектор должен думать наперед )
После простого "привет" и на этом всё, ясно что дальше ничего хорошего не воспоследует )
После простого "привет" и на этом всё, ясно что дальше ничего хорошего не воспоследует )
P
Там чел удалил сообщение с вопросом :)
Y
в таком случае архитектор должен сделать вид, что так и было задумано
IN
Архитектура просто должна быть достаточно гибкой. Agile.
IN
Если вам в рамках вашей архитектуры надо 2 часа , что бы у кнопки цвет поменять, значит это говнокод .)
Y
я просто не видел оригинального (удаленного впоследствии) вопроса и прочел все как сейчас написано. действительно ржачно )
+ пятница. ну все один к одному )
+ пятница. ну все один к одному )
2021 June 19
A
где в общем случае лучше конвертировать Flow<> из репозиториев в LiveData<>: в юзкейсе или вьюмодели? По идее во вьюмодели, потому что LiveData это платформенный способ обеспечить lifecycle awareness для presentation, верно?
AN
Юзкейс скорее должен содержать бинес логику, его конвертацией не надо грузить. Тут больше вопрос, хотите ли писать адаптер отдельный, тк возможно вы не хотите во вьюмодели ничего знать о флоу