MI
Речь не о проблемах. А о чистоте кода.
Проблем то не будет
Проблем то не будет
По мне это получше, чем методы а-ля getIconForSmth(): Int
Size: a a a
2020 March 02
DK
просто если это использовать для вьюшек, то я думаю ноом, но если пойдет в презетер и дальше, то эти R.color не нужны и легч4 создать расширение, которое будет получать цвет по этому енаму
AD
просто если это использовать для вьюшек, то я думаю ноом, но если пойдет в презетер и дальше, то эти R.color не нужны и легч4 создать расширение, которое будет получать цвет по этому енаму
совсем не понятно, какая проблема решается. если есть желание на каждый цвет в colors.xml обновлять еще и enum - да, задача выполнена)
а потом появятся цвета в атрибутах и в коде придется работать с ними и все сломается.
а потом появятся цвета в атрибутах и в коде придется работать с ними и все сломается.
DK
да тут дело такое:
есть выдвижная шторка. в ней менюшки
полный список этих менюшек определен в enum
из префов достается массив id и по этим id строится dataclass, с которым в дальнейшем идет работа. а инициализация этого dataClass-а ероисходит из значений данного enum-а
есть выдвижная шторка. в ней менюшки
полный список этих менюшек определен в enum
из префов достается массив id и по этим id строится dataclass, с которым в дальнейшем идет работа. а инициализация этого dataClass-а ероисходит из значений данного enum-а
А
Не думаю, что это по Code clean. Лучше разделять
А? Почему?
PA
Александр
А? Почему?
Как выше говорили, если это нужно для вью - то это будет уже не Клин код. Если для презентера - то там вообще пофиг, где ты разместишь эти значения.
А
Как выше говорили, если это нужно для вью - то это будет уже не Клин код. Если для презентера - то там вообще пофиг, где ты разместишь эти значения.
Не совсем понятно, почему это не клин код. Что мы там такого нарушили то.
AG
Как выше говорили, если это нужно для вью - то это будет уже не Клин код. Если для презентера - то там вообще пофиг, где ты разместишь эти значения.
Мне вот тоже интересно почему это не клин код?
K
Шок!11 енумы в UI не по клину! Чистота вопасносте!
AD
выходит, писать «чистый» код - грязно?
PA
выходит, писать «чистый» код - грязно?
😂
PA
Сами енумы никакого отношения к слою реализации не имеют. И пихать к ним параметры для вью просто не по фен-шую.
RM
AO
Сами енумы никакого отношения к слою реализации не имеют. И пихать к ним параметры для вью просто не по фен-шую.
Штоа?
K
но силд классы-то, силд классы-то можно? Пожалуйста, я очень хочу чтоб было клин, как с доктором Пропером, скажите, что можно!
AO
но силд классы-то, силд классы-то можно? Пожалуйста, я очень хочу чтоб было клин, как с доктором Пропером, скажите, что можно!
Только интерфейсы
2020 March 03
С
Это уже крайности, не бывает настолько чистой архитектуры
PA
Ребят, извиняюсь, я чёт напутал и пошло-поехало.
Не берите в счёт мои бредни про енумы 😂
Не берите в счёт мои бредни про енумы 😂
МE
Всем привет. Вопрос по CleanArc. Что есть сейчас: 2 экрана/2 презентера/2 интерактора/1 репозиторий. По сути сейчас имею дублирование кода в интеракторах для обращения к репе. Объединить 2 интерактора не могу - будет мусорка, разделись интеракторы по фичам/сущностям не могу, т.к. придётся в презентеры прокидывать N интеракторов. Смотрю пример Фернандо, у него там вообще плюшево сделано для одной сущности. Сейчас нет UseCase (для сущности, как говорил д.Боб), но делать их страшно, т.к. получится 1 экран / 1 презентер / N интеракторов / N UseCase. Какой опыт у вас?
I
1 экран, 1 презентер/вм, N UseCase