Когда использовать примитив против класса в Java?

Я вижу, что Java имеет логическое (класс) против логического (примитив). Аналогично, есть Integer (класс) против int (примитив). Как лучше всего использовать примитивную версию против класса? Должен ли я в основном всегда использовать версию класса, если у меня нет конкретной причины (производительности?), Чтобы не делать этого? Какой самый распространенный и приемлемый способ использования каждого?

В пункте 5 «Эффективной Явы» Джошуа Блох говорит

Урок ясен: предпочитайте примитивы коробочным примитивам и следите за непреднамеренным автобоксом .

Одно хорошее применение для классов - это когда они используются как универсальные типы (включая классы Collection, такие как списки и карты) или когда вы хотите преобразовать их в другой тип без неявного приведения (например, Integerкласс имеет методы doubleValue()или byteValue().

Изменить: причина Джошуа Блоха является:

// Hideously slow program! Can you spot the object creation?
public static void main(String[] args) {
    Long sum = 0L;
    for (long i = 0; i < Integer.MAX_VALUE; i++) {
         sum += i;
    }
    System.out.println(sum);
}

Эта программа получает правильный ответ, но она намного медленнее, чем должна быть, из-за односимвольной опечатки. Переменная sumобъявляется как a Longвместо a long, что означает, что программа создает около 2 ^ 31 ненужных Longэкземпляров (примерно по одному на каждый раз, когда объект long iдобавляется в Long sum). Изменение объявления суммы с Longна longсокращает время выполнения с 43 секунд до 6,8 секунд на моей машине.

Стандартной практикой является использование примитивов, если вы не имеете дело с генериками (убедитесь, что вы знаете об автобоксах и распаковках !).

Есть несколько веских причин следовать соглашению:

1. Вы избегаете простых ошибок:

Есть некоторые тонкие, не интуитивные случаи, которые часто выявляют новичков. Даже опытные программисты иногда допускают ошибки (возможно, за этим последует ругань, когда они отлаживают код и находят ошибку!).

Наиболее распространенной ошибкой является использование a == bвместо a.equals(b). Люди привыкли работать a == bс примитивами, поэтому это легко сделать, когда вы используете обертки объектов.

Integer a = new Integer(2);
Integer b = new Integer(2);
if (a == b) { // Should be a.equals(b)
    // This never gets executed.
}
Integer c = Integer.valueOf(2);
Integer d = Integer.valueOf(2);
if (c == d) { // Should be a.equals(b), but happens to work with these particular values!
    // This will get executed
}
Integer e = 1000;
Integer f = 1000;
if (e == f) { // Should be a.equals(b)
    // Whether this gets executed depends on which compiler you use!
}

2. Читабельность:

Рассмотрим следующие два примера. Большинство людей сказали бы, что второе более читабельно.

Integer a = 2;
Integer b = 2;
if (!a.equals(b)) {
    // ...
}
int c = 2;
int d = 2;
if (c != d) {
    // ...
}

3. Производительность:

Дело в том , что это медленнее использовать обертки объектов для примитивов , чем только с помощью примитивов. Вы добавляете стоимость создания объектов, вызовов методов и т. Д. К вещам, которые вы используете повсеместно .

Цитата Кнута "... скажем, в 97% случаев: преждевременная оптимизация - корень всего зла" на самом деле здесь не применима. Он говорил об оптимизации, которая делает код (или систему) более сложным - если вы согласны с пунктом 2, это оптимизация, которая делает код менее сложным!

4. Это соглашение:

Если вы сделаете другой стилистический выбор для 99% других Java-программистов, у вас будет два недостатка:

• Вам будет труднее читать код других людей. 99% примеров / учебников / и т. Д. Там будут использовать примитивы. Всякий раз, когда вы читаете один, у вас будут дополнительные когнитивные мысли о том, как это будет выглядеть в том стиле, к которому вы привыкли.
• Другим людям будет сложнее читать ваш код. Всякий раз, когда вы задаете вопросы о переполнении стека, вам придется просеивать ответы / комментарии, спрашивая: «Почему вы не используете примитивы?». Если вы мне не верите, просто посмотрите на битвы, которые люди ведут за такие вещи, как размещение скобок, что даже не влияет на сгенерированный код!

Обычно я бы перечислил некоторые контрапункты, но я, честно говоря, не могу придумать каких-либо веских причин не соглашаться здесь!

Обычно я иду с примитивами. Тем не менее, одной из особенностей использования таких классов, как Integerи Booleanявляется возможность присваивания nullэтим переменным. Конечно, это означает, что вы должны выполнять nullпроверки постоянно, но все же лучше получить исключение NullPointerException, чем иметь логические ошибки из-за использования некоторой переменной intили booleanпеременной, которая не была правильно инициализирована.

Конечно, начиная с Java 8 вы можете (и, вероятно, должны) пойти еще дальше и вместо, например Integer, можете использовать Optional<Integer>переменные, которые могут иметь или не иметь значение.

Кроме того, он предоставляет возможность использовать nullдля присвоения этим переменным значение « неизвестно » или « подстановочный знак ». Это может быть полезно в некоторых ситуациях, например, в Ternary Logic . Или вы можете проверить, соответствует ли определенный объект некоторому шаблону; в этом случае вы можете использовать nullте переменные в шаблоне, которые могут иметь любое значение в объекте.

По словам непрофессионала:

Вы используете обертки, когда вам нужно добавить вещи в коллекции.

Коллекции не могут содержать примитивы.

Java поддерживает авто-бокс, как указал m3th0dman. Подумайте о самом низком из возможных уровней, и вы увидите, что при автоматической упаковке (в или из) примитивное значение будет означать тактовые циклы, затрачиваемые на некоторые задачи, которые вам не нужны, если вы работаете с собственными типами данных вокруг своего приложения.

Как правило, вы должны стараться использовать собственные типы данных, когда это возможно.