Стандартна практика полягає в тому, щоб спілкуватися з примітивами, якщо ви не маєте справу з дженериками (переконайтеся, що ви знаєте про автобоксинг та розпакування !).
Є низка вагомих причин для дотримання конвенції:
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% прикладів / навчальних посібників / тощо там будуть використовувати примітиви. Кожного разу, коли ви читаєте його, у вас з'являться додаткові пізнавальні витрати, як думати про те, як це виглядатиме у стилі, до якого ви звикли.
- Інші люди будуть важче читати ваш код. Щоразу, коли ви задаєте питання щодо переповнення стека, вам доведеться просіювати відповіді / коментарі, запитуючи "чому ви не використовуєте примітиви?". Якщо ви не вірите мені, просто подивіться на бійки людей за такі речі, як розміщення дужок, що навіть не впливає на створений код!
Зазвичай я перелічу деякі зустрічні моменти, але я, чесно кажучи, не можу придумати жодних вагомих причин, щоб не піти з конвенцією тут!