(java || kotlin) && devOps
369 subscribers
6 photos
1 video
6 files
306 links
Полезное про Java и Kotlin - фреймворки, паттерны, тесты, тонкости JVM. Немного архитектуры. И DevOps, куда без него
Download Telegram
Всем привет!

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

Задавались ли вы вопросом: какие типы данных использовать в Java API - примитивные или типы-обвертки (boxed)?

Однонозначного ответа как водится нет, но есть ряд правил.

Плюсы примитивных типов:
1) занимают меньше памяти, т.к нет накладных расходов на Java объекты. Какой величины эти расходы - можно почитать тут: https://www.baeldung.com/jvm-measuring-object-sizes или посмотреть с шутками и прибаутками и хорошей дозой хардкора тут https://www.youtube.com/watch?v=3BmznLJAgaA

Плюсы обверток:
1) могут использоваться в generic-ах. А generic-и лежат в основе всяких разных фреймворков. Если вы не уверены, что не используете такие - то вот примеры: Mockito, Truth и AssertJ (см. https://t.me/javaKotlinDevOps/51), Hibernate
2) могут использоваться для передачи null значений. Да, не всегда это правильно, чаще неправильно, но такие кейсы бывают.

И если исходя из сказанного выше возникает мысль - может ну ее, эту производительность, пусть будет универсальный готовый к будущим изменениям код, то вот еще два фактора:

1) если в процессе написания кода потребуется boxing из примитивного типа в обвертку и наоборот, то в этих строчках кода могут возникать необъяснимые NPE. Особенно "хороши" такие NPE до Java 14)))
Примеры:
а)
Boolean variable;
if (variable) {
}
б)
Integer boxed;
int i = boxed;

Т.е. имеет смысл посмотреть на чужие API, которые мы используем и прикинуть, как часто придется преобразовывать типы.

2) код в настоящее стал достаточно гибким. В том плане, что если 50 лет назад для отладки программы нужно было набить код на перфокарте и дождаться своей очереди для ее исполнения на сервере, а 30 лет назад исправить большую Asm или C программу было тем еще приключением, то сейчас при правильном разбиении на микросервисы, использовании практик чистого кода и главное написании модульных тестов отрефакторить код не сложно. Если у вас не так - предлагаю над этим задуматься)

Итого:
1) Если нужны generic-и и\или придется часто преобразовывать в boxed типы - имеет смысл использовать их везде в своем API.
2) Если важна производительность - примитивы там, где большие объемы данных.
3) В остальных случаях предлагаю присмотреться к примитивам.
Если концепция поменялась - всегда есть рефакторинг. Чуть сложнее с Java API, выставленным наружу - выпущенным в виде библиотеки. Тут нас спасет версионирование API.

#java #types