Cuándo utilizar tipos primitivos y de referencia en Java

Question

En cuyo caso, ¿debe utilizar tipos primitivos (int) o tipos de referencia (Integer)?

Este question despertó mi curiosidad.

Answer 1

En cuyo caso se debe utilizar primitivas tipo (o tipos) int referencia (Integer)?

Como regla general, voy a utilizar una primitiva (como int) menos que tenga que utilizar una clase que envuelve una primitiva.

Uno de los casos eran uno debe utilizar una clase contenedora como Integer es en el caso de la utilización de generics, como Java no soporta el uso de tipos primitivos como los parámetros de tipo:

List<int> intList = new ArrayList<int>();    // Not allowed. 
List<Integer> integerList = new ArrayList<Integer>(); // Allowed. 

Y, en muchos casos, que se aprovecharán de autoboxing and unboxing, así que no tienen que realizar las conversiones de forma explícita primitivas a su clase de contenedor y viceversa:

// Autoboxing will turn "1", "2", "3" into Integers from ints. 
List<Integer> numbers = Arrays.asList(1, 2, 3); 

int sum = 0; 

// Integers from the "numbers" List is unboxed into ints. 
for (int number : numbers) { 
    sum += number; 
} 

también, como una nota adicional, al convertir de PRIMIT ives a sus objetos de clase contenedora, y las instancias únicas de objetos no son necesarias, use el método valueOf provisto por el método envoltorio, ya que realiza el almacenamiento en caché y devuelve la misma instancia para un cierto valor, reduciendo el número de objetos que se crean:

Integer i1 = Integer.valueOf(1); // Prefer this. 
Integer i2 = new Integer(1);  // Avoid if not necessary. 

para obtener más información sobre los métodos valueOf, la especificación API para el método Integer.valueOf puede servir de referencia para la forma en que esos métodos se comportarán de las clases contenedoras de primitivas.

Answer 2

Eso realmente depende del contexto. Primero prefiero el primitivo, porque es más intuitivo y tiene menos sobrecarga. Si no es posible por razones genéricas/de autoboxing, o si quiere que sea nulable, entonces elija el tipo de envoltorio (tipo complejo como lo llama).

Answer 3

Dado que Java hace algo llamado auto-boxing and auto-unboxing, debe usar el tipo primitivo int en la mayoría de los casos debido a una menor sobrecarga.

La única vez que necesitas usar Integer es en genéricos.

List<int> list; // won't compile 
List<Integer> list; // correct 

Answer 4

No creo que haya ninguna regla como tal. Elegiría los tipos sobre primitivos (entero sobre int) cuando escribo firmas de métodos, mapas, colecciones, objetos de datos que se pasan. Como tal, me gustaría usar Integer en lugar de int incluso dentro de los métodos, etc. Pero si crees que es demasiado problema (escribir "eger" extra), entonces está bien usar ints para las variables locales.

Answer 5

En lugar de llamarlos "tipos complejos", lo mejor sería pensar en Integer, Double, etc. como "Classes", y int, double, etc. como "primitives".

Si realiza cualquier tipo de matemática sofisticada, la representación numérica basada en la clase como Integer y Double será engorrosa y le ralentizará: muchas operaciones matemáticas solo se pueden realizar con primitivas.

Por otro lado, si intenta poner sus números en colecciones como Listas y Mapas, esas colecciones solo pueden contener objetos, y por lo tanto debe usar (o convertir a) clases como Entero y Doble.

Personalmente, utilizo primitivos cada vez que puedo salirse con la suya, y solo convierto a las representaciones de clase como entero cuando es hora de hacer entrada o salida, y el transporte requiere esas representaciones.

Sin embargo, si no está haciendo ninguna matemática en absoluto, y en su lugar solo está pasando los valores directamente a través de su código, puede ahorrarse algunos problemas tratando exclusivamente con los formularios basados ​​en clases (como Integer).

Answer 6

Si desea establecer la Atribución a la sesión, debe usar Objeto como Entero, Booleano, Cadena en servlets. Si desea usar el valor, puede usar tipos primitivos. Los objetos pueden ser nulos pero no primitivos. Y si quiere comparar tipos para primitivos, use == pero los objetos usan .equals porque en la comparación de objetos == no busca valores, busca si estos son los mismos objetos. Y el uso de primitivas hace que el código sea más rápido.

Answer 7

Un caso en el que podría preferirse Integer es cuando está trabajando con una base de datos donde las entradas numéricas pueden ser nulas, ya que no podría representar un valor nulo con un int.

Pero, por supuesto, si estás haciendo cálculos rectos, entonces int sería mejor que otros han mencionado debido a la intuición y menos sobrecarga.

Answer 8

Las normas generales que seguir al crear una API se pueden resumir de la siguiente manera:

1. Si el método debe devolver un valor, utilice un tipo primitivo
2. Si el método no se puede aplicar siempre (por ejemplo: getRadioId (...) en un objeto donde tal ID no existe), luego devuelve un Entero y especifica en los JavaDocs que el método devolverá nulo en algunos casos.

En el n. ° 2, tenga cuidado con los NPE al autoboxing. Si usted tiene un método definido como:

public Integer getValue(); 

y luego llamar de la siguiente manera:

int myValue = getValue(); 

En el caso en que getValue() devuelva null obtendrá un NPE sin una causa obvia.

Answer 9

Mi regla de oro es: use primitivas encuadradas solo cuando sea necesario para compilar el código. Los únicos lugares en su código donde deben aparecer los nombres de las clases de envoltura primitivas se encuentra en parámetros de tipo genérico y el método estático llama:

List<Integer> intList = new ArrayList<Integer>(); 

int n = Integer.parseInt("123"); 

Ese es el consejo que daría a los nuevos programadores de Java. A medida que aprenden más, se toparán con situaciones en las que tendrán que ser más exigentes, como cuando se trata de mapas o bases de datos, pero para entonces también deberían tener una mejor comprensión de la diferencia entre primitivos y primitivos encuadrados.

Autoboxing nos tienta a creer que int y Integer (por ejemplo) son intercambiables, pero es una trampa. Si mezcla los dos tipos de valor indiscriminadamente, puede terminar comparando dos valores enteros con == o tratando de unbox null sin darse cuenta. Los errores resultantes pueden ser intermitentes y difíciles de rastrear.

No ayuda que la comparación de primitivas en caja con ==a veces funciona como si estuviese haciendo una comparación de valores. Es una ilusión causada por el hecho de que los valores dentro de un cierto rango se almacenan en caché automáticamente en el proceso de autoboxing. Es el mismo problema que siempre hemos tenido con los valores de Cadena: compararlos con == a veces "funciona" porque en realidad está comparando dos referencias al mismo objeto en caché.

Cuando trabajamos con cadenas, podemos decirle a los n00bs que nunca las comparen con ==, como lo hemos estado haciendo todo el tiempo. Pero comparar primitivas con == es perfectamente válido; el truco (gracias al autoboxing) es asegurarse de que los valores realmente sean primitivos. El compilador ahora nos permitirá declarar una variable como Integer y usarla como si fuera int; eso significa que tenemos que ejercer un mayor nivel de disciplina y tratarlo como un error cuando alguien lo hace sin una buena razón.

Answer 10

Creo que es un poco tarde, pero quería agregar mi opinión por si acaso.

En algunos casos, es necesario utilizar los contenedores ya que la falta de un valor es diferente del valor predeterminado.

ejemplo, para un proyecto que trabajé, había un campo en la pantalla donde el usuario puede introducir un valor doble, el requerimiento del negocio menciona claramente que si el usuario introduce un 0 el significado es diferente de no introducir un valor y dejando el campo en blanco y esta diferencia tendrá un impacto más adelante en un módulo diferente. así que en este escenario tuvimos que usar el objeto Double, ya que no puedo representar una falta de valor usando la primitiva; ya que la primitiva por defecto será 0, que era una entrada válida para el campo.