ну если бы у нас был бы ооп холивар,я бы сказал что не кошерный ооп

но это не к ооп

хотя как бы да,это не кошерный ооп

егора на вас нет

я правильно понимаю, что лучше enum не использовать, потому что это дерьмо?

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

это как знаете свич по типам

лол никак не могу понять о чём речь. можно пример как делать плохо

data class Message(type: MessageType, text: String) - никогда так не делайте

enum class MessageType { VOICE, TEXT, VIDEO}

ага... а нужно тип sealed для 3х месаджей?

если вы потом делаете switch по MessageType,то у вас хреновый ооп

очень такой хреновый

не думал что это ооп.

да, sealed class Message { data class TextMessage(...) data class VoiceMessage(...) ... }

ну вы когда на джаве пишите

вы же свич по типам не делаете?

так и тут

а если есть 2 поля с енумами?

2 поля с енамами?

привести пример?

ну

ну допустим у нас есть поездка или билет там указывается тип багажа и класс комфорта (эконом/бизнес/етц)

не очень жизненно с типом багажа но допустим такое бывает

вот даже часть из clean code: G23: Prefer Polymorphism to If/Else or Switch/Case

Ну это немного другое. Тут по факту не тип самого объекта, а тип одного из его полей.

как еще пример: класс такси - цвет машины, класс машины, квалификация водителя (профессионал, новичок ...)

вот норм

Ну это немного другое. Тут по факту не тип самого объекта, а тип одного из его полей.

об этом и речь. разговор о том, что плохо использовать enum как поле data class

речь идет про то,что если у тебя есть сраный меседж

у него внутри лежит тайп

то ты гавнокодер

вот и все

речь идет про основной признак

окей

если так угодно

если их более одного,это другой кейс

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

речь про основной тип/критерий

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

у него внутри лежит тайп

Тип в типе это говнокод?

data class Message(type: MessageType, text: String) - да

я бы даже сказал лютый гавнокод

А, понял о чём ты

Я думал любой)

Он определяет тип так что ли через поле?

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

то все у вас хреново

аа лол у вас аватарки одинаковые. я думал что сам с собой спорит.

одному из них нужно на аву логотип dart

в основном мне больше нравится fun chtototam(enum: Enum) = when (enum) {

не,я пока не поддался этой балалайке

чем лезть в методы енума

хотя флатер вроде как такой модный весь прям реакт

чем лезть в методы енума

методы?

ну я про этот ооп подход

заменять все ветвления на полиморфизм

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

но когда у вас в проекте половина кода - свичи по типам

это зашквар

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

так я и пытаюсь это обьяснить, что есть грань.

самое крутое что видел,это интерфейс Item с методом isItem возвращающим INT(не бульку,а инт карл) и потом по нему матчилось в адаптере

так я и пытаюсь это обьяснить, что есть грань.

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

а когда вы начинаете перечислять про машину

блин, recycleView Adapter так работает, и ничего

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

блин, recycleView Adapter так работает, и ничего

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

ERROR: S client not available

но да ладно

я про то, как recycle view понимает, какой из ViewHolder использовать

полиморфизм :D

бинд уже

а создание - фабрика/anything else

но да,в эту фабрику/что-то еще кидается сраный viewtype из адаптера

но

это адаптер,который по своей природе занимается адаптированием разных данных в примерно общий вид (view)

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

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

тесты то не все даже пишут

ну кстати к вашему примеру про машину,это примерно если бы вы хранили в одном из полей объект,в котором у вас лежал бы инт и тип его

который мог быть например цветом в инте, номером телефона или размером багажника

вот примерно такая аналогия

так есть поле

в нём объект

в объекте инт

и его тип является цветом в инте

вы опять втираете мне дич

цвет в инте это уже цвет

ему тип не нужен

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

например

если вы в зависимости от типа берете разные филды в качестве имени например

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

а вы решили а че будет один обьект с енамом внутри

и буду хранить сразу и название компании и имя и прочее дерьмо

и тип указывать юр лицо или физ

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

то я бы ваш код на ревью реджектнул

и вот допустим этот кейс

класс такси - цвет машины, класс машины, квалификация водителя (профессионал, новичок ...)