Este tema puede parecer simple pero no lo es tanto, imaginen un escenario como este
class Sobrecarga{
public void metodo(byte b){
System.out.println("byte");
}
public void metodo(int i){
System.out.println("int");
}
public void metodo(long l){
System.out.println("long");
}
public void metodo(double d){
System.out.println("double");
}
}
¿Que se imprimiría en pantalla cuando llamemos a “metodo” con un parámetro de un short?
Sobrecarga sc = new Sobrecarga();
short s = 18;
sc.metodo(s);
La respuesta es
int
¿Pero porque?
Bien, lo primero que trata de hacer el compilador para decidir cuál método ejecutara es buscar la que tenga el parámetro más pequeño tal que el tipo del argumento quepa en él. En este caso la versión del método con el parámetro más pequeño donde quepa un short es la de int,
¿Por qué no byte, acaso 18 no cabe en un byte?
Si pero esto se hace en tiempo de compilación eso significa que si la variable tiene 18, -1 o chorro cientos no importa lo que importa es el tipo de la variable.
Clases de envoltorio
Existe una clase de envoltorio para cada tipo primitivo de java, todas tienen el mismo nombre de su respectivo primitivo pero empiezan con mayúscula (al ser clases), excepto claro por Integer de int y Character de char.
Existen dos grandes y maravillosas características introducidas a estas en la versión 1.5 de java, llamadas unboxing (digamos desenvolver) y autoboxing (¿envolver en automático?).
int primitivo = 6;
Integer envoltura = primitivo; /*autoboxing (¡se está envolviendo solita!, pasa de ser primitivo a ser un objeto de su envoltorio pues)*/
primitivo = envoltura; //outboxing (se desenvuelve)
¿Porque vemos esto para métodos sobrecargados?
Porque podemos tener algo como esto:
public class Sobrecarga{
public void metodo(Byte b){
System.out.println("Byte");
}
public static void main(String[] args){
Sobrecarga sc = new Sobrecarga();
byte prim = 9;
sc.metodo(prim);
}
}
Esto imprime en pantalla
Byte
¿Por qué?
Pues porque la variable prim de tipo byte hizo auto-boxing para convertirse en un Byte.
Ahora sí ¿qué prefiere el compilador, hacer auto-boxing o usar un tipo de mayor tamaño?
public class Sobrecarga{
public void metodo(Byte b){
System.out.println("Byte");
}
public void metodo(long l){
System.out.println("long");
}
public static void main(String[] args){
Sobrecarga sc = new Sobrecarga();
byte prim = 9;
sc.metodo(prim);
}
}
Lo anterior imprimirá long
De eso concluyo, advertencia no me consta. “El compilador prefiere desperdiciar bits (recordar que un casting añade bits) a desperdiciar tiempo de ejecución (auto-boxing)". Lo siguiente apoyara mi teoría.
Var-args (Argumentos variables o algo así)
No sé qué tanto tienen existiendo pero no los conocía, los var-args son en realidad arrays (y por lo tanto objetos), pero con flexibilidad a la hora de pasarlos como argumentos.
Al tener un escenario como este:
public class VarArgs{
public void metodo(int... n){
System.out.println("int...n");
}
public static void main(String [] args){
VarArgs va = new VarArgs();
va.metodo();//1
va.metodo(5);//2
va.metodo(1,2,5);//3
va.metodo(null);//4
va.metodo(new int[]{4,5,6});//5
}
}
El código anterior no produce ningún error de compilación, los var-args pueden recibir una lista de 0 o más enteros (líneas comentadas con 1,2 y 3), pero como en realidad es un array puede recibir cualquier valor posible para un array (4 y 5). Piensen un momento “¿si yo fuera compilador me daría flojera dar soporte a esto?”, pues pasa algo así pues volviendo al tema de los métodos sobrecargados el compilador solo escogerá el método con var-args si y solo si no tiene otra opción.
Ejemplo
public class VarArgs{
public void metodo(Object o){
System.out.println("Object");
}
public void metodo(int... n){
System.out.println("int...n");
}
public static void main(String [] args){
VarArgs va = new VarArgs();
int i =9;
va.metodo(i);
}
}
El código anterior imprimirá
Object
¿Porque?
El compilador prefiere hacer auto-box (pasar de int a Integer) y después pasar la clase de Integer a Object, en vez de poner al solitario int en un array.
No hay comentarios:
Publicar un comentario