Sealed-классы и моделирование состояний
Вопрос
Как ты моделируешь состояние экрана или результат операции в Kotlin? Почему sealed?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Sealed-иерархия: Loading, Content, Error как отдельные типы
У каждого варианта свои данные, невозможные комбинации не выразить
when по sealed полный, else не нужен, компилятор ловит забытые ветки
Наследники в том же модуле и пакете
data object для вариантов без данных
Что могут спросить следом
- Почему не набор nullable-полей и флагов?
- Чем sealed interface лучше sealed class?
- Как сериализовать sealed-иерархию?
Разбор
Для состояния экрана я использую sealed interface с вариантами Loading, Content(items) и Error(message). Альтернатива из флагов isLoading, items, error допускает невозможные комбинации, например одновременно загрузку и ошибку, и каждое место кода должно их разбирать. В sealed-иерархии у каждого варианта ровно свои данные. Главный плюс: when по sealed-типу проверяется компилятором на полноту, поэтому else не пишу специально: добавлю новый вариант, и сборка покажет все места, где его надо обработать. Наследники должны лежать в том же модуле и пакете. Варианты без данных делаю data object, чтобы был нормальный toString. Sealed interface предпочитаю sealed class, потому что вариант может реализовать несколько интерфейсов и не тащит конструктор базового класса.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.