Nullable в публичном API
Вопрос
Как ты решаешь, делать ли тип в API nullable? Что предпочитаешь вместо null?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Null только если отсутствие значения является нормальным состоянием
Пустая коллекция лучше, чем nullable-коллекция
Для ошибок лучше sealed-результат или исключение, а не null
Для «нет значения» с причиной лучше sealed-класс состояния
На границе с Java ставить аннотации nullability
Что могут спросить следом
- Чем
Result<T>из stdlib плох для бизнес-ошибок? - Как null-safety работает с Gson и рефлексией?
Разбор
Я делаю тип nullable только тогда, когда отсутствие значения это нормальная часть домена: у пользователя может не быть аватара. Если же null означает ошибку, лучше явный тип: sealed-иерархия вроде Success, NotFound, NetworkError или исключение для действительно исключительных ситуаций. Коллекции почти никогда не делаю nullable: пустой список честнее и избавляет вызывающий код от проверок. Для состояний экрана вместо набора nullable-полей использую sealed-класс Loading, Content, Error, тогда невозможные комбинации не выразить. На границе с Java и в библиотеках ставлю аннотации nullability, чтобы Kotlin видел нормальные типы, а не платформенные. И отдельно помню, что рефлексия вроде Gson может положить null в non-null поле, поэтому для JSON лучше kotlinx.serialization или Moshi с кодогенерацией.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.