543 слова
ПОЧЕМУ ЭТО ВАЖНО: предсказуемое программное обеспечение содержит меньше ошибок.
- NPE выбрасываются, когда мы их не ожидаем.
- Ошибка на миллиард долларов — это ЛОЖЬ.
Когда я слышу «нулевую безопасность», я вспоминаю это:
Не верьте своим глазам. Иногда соль выглядит как сахар.
ПОГРУЖАЙТЕСЬ: Kotlin и Java живут в симбиозе.
- Оба они работают на виртуальной машине Java.
- Они оба компилируются в один и тот же байт-код.
- Вы можете использовать класс Java в коде Kotlin и наоборот.
Они должны играть по тем же правилам. Как это возможно, что один язык предлагает нулевую безопасность, а другой нет?
Они НЕ ДОЛЖНЫ, а Kotlin еще более опаснее.
Kotlin предлагает безопасные вызовы, избавляющие от шаблонного кода.
Котлин
return parent?.child?.grandchild?.age ?: 0
Ява
if (parent != null) { if (parent.child != null) { if (parent.child.grandchild != null) { return parent.child.grandchild.age; } } } return 0;
Меньше шаблонов помогает нам быстро выявлять проблемы. Все во время компиляции. Это очень удобно. Это причина называть Kotlin null безопасным?
ПЕРВЫЙ ПРИМЕР: Остерегайтесь типов Plaftorm.
- Тип платформы — это чистый тип Java без модификаторов (аннотаций вроде @Nullable или @NotNull).
- Он может быть как строгим, так и необязательным. Вам решать.
Такому типу нельзя доверять. Если это может быть null, но не обязательно, по умолчанию его следует считать допускающим значение null.
ВТОРОЙ ПРИМЕР: универсальные типы Java и Kotlin выглядят одинаково.
Использование универсальных типов Java в Kotlin возлагает ответственность на программиста.
- Необязательные типы требуют безопасных вызовов (к счастью).
- Строгие типы становятся типами платформы.
ТРЕТИЙ ПРИМЕР. Никогда не знаешь, что возвращают внешние службы.
- Приложения подключаются к некоторым третьим сторонам (например, Backend).
- Даже если договор согласован, он может измениться.
Разработка сервиса, с которым интегрируются другие, чрезвычайно сложна в обслуживании. Небольшое изменение, несовместимое с предыдущими версиями, может нарушить работу клиентов.
У меня есть правило: Не доверять третьим лицам. Следовательно, все из бэкэнда считается обнуляемым.
Давайте посмотрим пример.
Поскольку Kotlin позволяет мне использовать функции Java, я могу использовать REFLECTION.
Использование рефлексии считается ошибкой в профессиональном развитии.
Это тоже ложь…
Я не говорю использовать отражение в вашем производственном коде. Я говорю, что это чрезвычайно полезно в библиотеках.
- jUnit — использует отражение.
- Мокито? - отражение.
- Бьюсь об заклад, вы не разбираете JSON самостоятельно, а вместо этого используете библиотеку. ГСОН? — опять отражение!
Очень важно, чтобы все, что приходит из-за пределов вашего приложения, считалось обнуляемым.
Если вы этого не сделаете, вы можете оказаться в состоянии, когда компилятор говорит, что значение не может быть нулевым, но мы уже знаем, что это возможно.
Такой нуль может тихо существовать в вашем приложении, пока вы не выполните операцию над объектом, на который ссылается нуль.
ИТОГОВАЯ ЛИНИЯ: NPE выбрасываются, когда они не ожидаются.
Вы бы никогда не написали такое.
Я думаю, поэтому это не выделено. Вы ОЖИДАЕТЕ, что после такой команды ваше приложение перестанет работать.
Это не значит, что нули — это плохо.
Те из вас, кто когда-либо ссорился со своей второй половинкой, знают, что, сказав ЧТО-ТО, вы можете совершить большую ошибку, но, сказав НИЧЕГО, может быть еще хуже.
Нули существуют. Мы должны научиться их использовать вместо того, чтобы пытаться найти обходной путь, потому что это неудобно.
Спроектируйте свой код так, чтобы он был ПРЕДСКАЗУЕМЫМ, остальное исправится само.
Вам понравилась история? Оставляйте комментарии и не забывайте хлопать.