Envolver, desenvolver y embalar

¡Hola! Ya está bastante familiarizado con los tipos primitivos y ha trabajado mucho con ellos. Los primitivos en programación, y en Java en particular, tienen muchas ventajas: ocupan poca memoria, lo que aumenta la eficiencia del programa, y ​​están claramente divididos en rangos de valores. Sin embargo, en el proceso de aprendizaje de Java, hemos repetido más de una vez, a modo de mantra, “ en Java todo es un objeto ”. Pero los primitivos son una refutación directa de estas palabras. No son objetos. Entonces, ¿el principio “todo es un objeto” es falso? No precisamente. En Java, cada tipo primitivo tiene su hermano gemelo, la clase contenedora ( Wrapper). ¿Qué es un envoltorio? Un contenedor es una clase especial que almacena el valor de una primitiva dentro de sí misma. Pero como se trata de una clase, puede crear sus propias instancias. Almacenarán los valores primitivos necesarios en su interior, siendo al mismo tiempo objetos reales. Los nombres de las clases contenedoras son muy similares a los nombres de las primitivas correspondientes, o coinciden completamente con ellos. Por tanto, será muy fácil recordarlos. Los objetos de clase contenedora se crean como cualquier otro:

public static void main(String[] args) {

   Integer i = new Integer(682);

   Double d = new Double(2.33);

   Boolean b = new Boolean(false);
}

Las clases contenedoras le permiten mitigar las desventajas que tienen los tipos primitivos. La más obvia es que las primitivas no tienen métodos . Por ejemplo, no tienen un método toString(), por lo que no puedes, por ejemplo, convertir un número inten una cadena. Pero con una clase contenedora Integeres fácil.

public static void main(String[] args) {

   Integer i = new Integer(432);

   String s = i.toString();
}

También habrá dificultades con la transformación inversa. Digamos que tenemos una cadena que sabemos con certeza que contiene un número. Sin embargo, en el caso de un tipo primitivo, intno podremos obtener este número de la cadena y convertirlo, de hecho, en un número. Pero gracias a las clases contenedoras, ahora tenemos esta oportunidad.

public static void main(String[] args) {

   String s = "1166628";

   Integer i = Integer.parseInt(s);

   System.out.println(i);
}

Salida: 1166628 Hemos recuperado con éxito un número de una cadena y lo asignamos a una variable de referencia Integer i. Por cierto, sobre enlaces. Ya sabes que los parámetros se pasan a los métodos de diferentes maneras: las primitivas se pasan por valor y los objetos se pasan por referencia. Puede utilizar este conocimiento al crear sus métodos: si su método funciona, por ejemplo, con números fraccionarios, pero necesita la lógica de pasar por referencia, puede pasar parámetros al método Double/Floaten lugar de double/float. Además, además de los métodos, las clases contenedoras tienen campos estáticos que son muy convenientes de usar. Por ejemplo, imagine que ahora se enfrenta a una tarea: imprimir el número máximo posible en la consola inty luego el número mínimo posible. La tarea parece elemental, pero aun así difícilmente podrás realizarla sin Google. Y las clases contenedoras le permiten resolver fácilmente los siguientes "problemas cotidianos":

public class Main {
   public static void main(String[] args) {

       System.out.println(Integer.MAX_VALUE);
       System.out.println(Integer.MIN_VALUE);
   }
}

Estos campos le permiten no distraerse de tareas más serias. Sin mencionar el hecho de que en el proceso de imprimir el número 2147483647 (esto es exactamente MAX_VALUE) no es sorprendente que se escriba mal :) Además, en una de las conferencias anteriores ya llamamos la atención sobre el hecho de que los objetos de clases contenedoras son inmutables (Inmutable) .

public static void main(String[] args) {

   Integer a = new Integer(0);
   Integer b = new Integer(0);

   b = a;
   a = 1;
   System.out.println(b);
}

Salida: 0 El objeto al que apuntaba originalmente la referencia аno ha cambiado su estado; de lo contrario, el valor btambién habría cambiado. Al igual que con String, en lugar de cambiar el estado del objeto contenedor, se crea un objeto completamente nuevo en la memoria. ¿Por qué los creadores de Java finalmente decidieron mantener los tipos primitivos en el lenguaje? Dado que todo debería ser un objeto y ya tenemos clases contenedoras que se pueden usar para expresar todo lo que expresan las primitivas, ¿por qué no simplemente dejarlas en el lenguaje y eliminar las primitivas? La respuesta es sencilla: rendimiento. Los tipos primitivos se denominan primitivos porque carecen de muchas características "pesadas" de los objetos. Sí, un objeto tiene muchos métodos convenientes, pero no siempre los necesitas. A veces solo necesitas el número 33, o 2,62, o el valor de true/ false. En situaciones donde todos los beneficios de los objetos no son importantes y no son necesarios para que el programa funcione, las primitivas harán un trabajo mucho mejor.

Embalaje/desembalaje automático

Una de las características de las primitivas y sus clases contenedoras en Java es el autoboxing/autounboxing. Entendamos este concepto. Como usted y yo ya aprendimos antes, Java es un lenguaje orientado a objetos. Esto significa que todos los programas escritos en Java están formados por objetos. Los primitivos no son objetos. Sin embargo, a la variable de clase contenedora se le puede asignar un valor de tipo primitivo. Este proceso se llama autoboxing . De la misma manera, a una variable de tipo primitivo se le puede asignar un objeto de una clase contenedora. Este proceso se llama autounboxing . Por ejemplo:

public class Main {
   public static void main(String[] args) {
       int x = 7;
       Integer y = 111;
       x = y; // desempaquetado automático
       y = x * 123; // embalaje automático
   }
}

En la línea 5, asignamos a la primitiva x el valor de y, que es un objeto de la clase contenedora Integer. Como puede ver, no se necesitan acciones adicionales para esto: el compilador lo sabe inty Integer, de hecho, hace lo mismo . Esto es desembalaje automático. Lo mismo sucede con el autoboxing en la línea 6: al objeto y se le asigna fácilmente el valor de las primitivas (x*123). Este es un ejemplo de empaquetado automático. Por eso se agrega la palabra “auto”: para asignar referencias primitivas a objetos de sus clases contenedoras (y viceversa) no necesitas hacer nada, todo sucede automáticamente . Conveniente, ¿verdad? :) Otra gran conveniencia del empaquetado y desempaquetado automático se manifiesta en el funcionamiento de los métodos. El hecho es que los parámetros del método también están sujetos a empaquetado y desempaquetado automático . Y, por ejemplo, si uno de ellos toma dos objetos como entrada Integer, ¡podemos pasar fácilmente primitivas ordinarias allí int!

public class Main {
   public static void main(String[] args) {

       printNumber(7);//int regular, incluso sin una variable
   }

   public static void printNumber(Integer i) {
       System.out.println("Usted ingresó un número" + i);
   }
}

Resultado: Ingresaste el número 7. Funciona al revés:

public class Main {
   public static void main(String[] args) {

       printNumber(new Integer(632));
   }

   public static void printNumber(int i) {
       System.out.println("Usted ingresó un número" + i);
   }
}

Un punto importante para recordar: ¡ el autoboxing y unboxing no funcionan para matrices !

public class Main {
   public static void main(String[] args) {

       int[] i = {1,2,3,4,5};

       printArray(i);// error, no se compila!
   }

   public static void printArray(Integer[] arr) {
       System.out.println(Arrays.toString(arr));
   }
}

Intentar pasar una matriz de primitivas a un método que toma una matriz de objetos como entrada provocará un error de compilación. Finalmente, comparemos una vez más brevemente las primitivas y las envoltorios Primitivas:

• tener una ventaja de rendimiento

Envoltorios:

• Permiten no violar el principio “todo es un objeto”, por lo que los números, símbolos y valores booleanos verdadero/falso no quedan fuera de este concepto.
• Amplíe la capacidad de trabajar con estos valores proporcionando métodos y campos convenientes
• Necesario cuando algún método puede funcionar exclusivamente con objetos.