Null safety of Kotlin. Мысль про киллер фичу
Познакомившись впервые с языком Котлин после продолжительной работы с Java меня воротило от одной мысли, что null-safety может быть полезен и вообще переменная без null — примитив, но я сам этого не осознавал.
Как это проявлялось:
Не удобно работать с переменными и филдами, у которых не может быть null. Ну просто даже не понимал, как что-то не может быть null.
Не удобно работать с nullable типами. Ну блин ?: !
Вообщем шло время, потихоньку начинал привыкать к тому, что null может не существовать, даже пытался сделать что-то на мой тот взгляд идиоматичное: дефолтные значения в виде объекта… Вообщем все это меня вгоняло в тоску и я очень хотел опять писать на Java, так как привык жить с null. Прошло время я уже нормально начал жить с котлиновским not nullable, как в друг в один прекрасный день я вернулся в Java… И через время осознал одну вещь:
Когда я работаю с легаси кодом (ну это весь код, который вообще пишется), то я не понимаю, где у может быть null, а где нет, что заставляет меня делать переключение контекста от реализации бизнес логики на выяснение:, а может ли тут быть null?
Рассмотрим синтетику: У нас есть сущность номер телефона с филдами: номер, международный код города и префикс (ну +7, +3 и т.д.), написана она до нас, есть мэппинг в базу, вообщем все по канонам кровавого. По бизнесу все 3 поля номера телефона обязаны быть.
Если я в Java, то при работе с этой сущностью у меня есть сколько вариантов как ее использовать:
Использовать как есть, не думая о том, что там с null-ам (продакшен разберется, если что баг пофиксим)
Дойти до базы данных и посмотреть на констрейнт, тем самым убедившись, что null там не может быть и можно спокойно юзать эту сущность без проверок.
Если расставлены аннотации @NotNull, нажать Ctrl+Q, чтобы увидеть описание.
Обработать все поля, предполагая, что везде может быть null.
Написать свой код, потом разобраться с потенциальным null.
Можно еще придумать варианты…
Все, кроме первого варианта, заставляют меня приложить усилия на переключение контекста и отвлечься от основной мысли над которой я работаю, ну да пункт 5 может сохранить мое внимание какое-то время, но потом прийдется потратить еще кучу времени на переключение контекста. Первый в принципе не плох, но потом будет весело разбираться с NPE.
Какие у нас есть варианты в Котлин:
Значение филда может быть null и я могу сразу обработать такой кейс.
Значение не может быть null.
То есть оба варианта не сбивают меня, не заставляют меня переключить свое внимание.
Конечно тут можно возразить, что есть совместимость с Java и там все плохо в этом плане, на что есть такой ответ: совместимость это круто, но как он сделан, это трейд офф, чтобы не плодить море конструкций вида ! ?:
Ну и еще раз про само свойство null safety: это не совсем техническая штука, скорее это про бизнес, если у меня в бизнесе какое-либо значение не может быть null, так пусть оно упадет на ранних этапах, чем с каким-то null жить.
