Standardową praktyką jest stosowanie prymitywów, chyba że masz do czynienia z lekami generycznymi (upewnij się, że wiesz o automatycznym pakowaniu i rozpakowywaniu !).
Istnieje wiele dobrych powodów, aby przestrzegać konwencji:
1. Unikasz prostych błędów:
Istnieją pewne subtelne, nieintuicyjne przypadki, które często łapią początkujących. Nawet doświadczeni koderzy czasami wpadają w błąd i popełniają te błędy (miejmy nadzieję, że po tym debugują kod i wykrywają błąd!).
Najbardziej powszechnym błędem jest użycie a == bzamiast a.equals(b). Ludzie są przyzwyczajeni do robienia a == bprymitywów, więc łatwo to zrobić, gdy używasz opakowań obiektów.
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. Czytelność:
Rozważ następujące dwa przykłady. Większość ludzi powiedziałaby, że druga jest bardziej czytelna.
Integer a = 2;
Integer b = 2;
if (!a.equals(b)) {
// ...
}
int c = 2;
int d = 2;
if (c != d) {
// ...
}
3. Wydajność:
Faktem jest, że jest wolniej używać obwolut obiektu dla prymitywów niż tylko za pomocą prymitywów. Dodajesz koszty tworzenia instancji obiektów, wywołań metod itp. Do rzeczy, których używasz wszędzie .
Cytat Knutha „… mówią w 97% przypadków: przedwczesna optymalizacja jest źródłem wszelkiego zła” tak naprawdę nie ma tutaj zastosowania. Mówił o optymalizacjach, które czynią kod (lub system) bardziej skomplikowanym - jeśli zgadzasz się z punktem # 2, jest to optymalizacja, która sprawia, że kod jest mniej skomplikowany!
4. To konwencja:
Jeśli wybierzesz inne opcje stylistyczne niż 99% innych programistów Java, istnieją 2 wady:
- Kod innych osób będzie trudniejszy do odczytania. 99% przykładów / samouczków / etc będzie używać prymitywów. Za każdym razem, gdy je czytasz, będziesz miał dodatkowe koszty poznawcze związane z myśleniem o tym, jak wyglądałby w stylu, do którego jesteś przyzwyczajony.
- Dla innych osób twój kod będzie trudniejszy do odczytania. Ilekroć zadajesz pytania na temat przepełnienia stosu, będziesz musiał przeszukiwać odpowiedzi / komentarze, pytając „dlaczego nie używasz prymitywów?”. Jeśli mi nie wierzysz, spójrz na bitwy toczone przez ludzi, takie jak umieszczanie nawiasów, co nawet nie wpływa na generowany kod!
Zwykle wymieniam kilka kontrapunktów, ale szczerze mówiąc, nie mogę wymyślić żadnego dobrego powodu, aby nie iść tutaj na konwencję!