java - proyecto - Importar paquete.*Vs paquete de importación. Tipoespecífico
paquetes en java ejemplos (10)
Esta pregunta ya tiene una respuesta aquí:
¿Supondría alguna diferencia con respecto a la sobrecarga escribir una importación cargando todos los tipos dentro de un paquete ( import java.* ); que solo un tipo específico (es decir, import java.lang.ClassLoader )? ¿El segundo sería una forma más recomendable de usar que el otro?
Después de buscar más información, encontré este sitio web donde está muy bien explicado. Problema de importación y ¿Usar * en una declaración de importación afecta el rendimiento? .
¿Hay algún problema de eficiencia entre estos dos estilos? Posiblemente, pero como las declaraciones de importación no importan nada en su programa, cualquier diferencia es muy pequeña. Recuerde que hay una implícita importación java.lang. * En la parte superior de sus unidades de compilación, y java.lang en JDK 1.2.2 contiene 75 clases e interfaces. Un experimento que utiliza un ejemplo artificial, uno con miles de usos de nombres de clases que deben buscarse, mostró un cambio insignificante en la velocidad de compilación. Por lo tanto, el rendimiento de compilación probablemente no se debe considerar un factor al elegir un formato sobre otro.
Hay un último ángulo de interés en las declaraciones de importación. Supongamos que usa una clase interna:
package P;
public class A {
public static class B {}
}
Si desea acceder a A desde otra unidad de compilación, diga:
import P.*;
o: importar PA; Pero si desea acceder a B sin calificación, debe decir:
import P.A.*;
o: importar PAB; El primero de ellos pone a disposición los tipos dentro de la clase A que se encuentra en el paquete P. El segundo pone a disposición solo el tipo B que se encuentra en la clase A en el paquete P.
Eche un vistazo a la API de Java, y verá muchas clases e interfaces con el mismo nombre en diferentes paquetes.
Por ejemplo:
java.lang.reflect.Array
java.sql.Array
Por lo tanto, si importa java.lang.reflect.* Y java.sql.* , Tendrá una colisión en el tipo de matriz y tendrá que calificarlos completamente en su código.
Importar clases específicas en su lugar le ahorrará esta molestia.
Es más una buena práctica de codificación ya que cualquier persona que lea su código sabrá de inmediato qué clases utiliza una clase en particular con tan solo mirar el bloque de importación en la parte superior del archivo, mientras que tendría que excavar para averiguar si utilizó comodines.
Este es realmente un problema muy malo.
Supongamos que escribes
import a.*;
import b.*;
...
Foo f;
y la clase Foo existe en el paquete a.
Ahora comprueba el código de compilación perfecto y, seis meses más tarde, alguien agrega la clase Foo al paquete b. (Tal vez es una lib de un tercero que agregó clases en la última versión).
¡Maricón! Ahora su código se niega a compilar.
Nunca use importación a pedido. ¡Es malvado!
http://javadude.com/articles/importondemandisevil.html para más detalles.
Rendimiento de RE:
import a.*;
vs
import a.X;
No hace diferencia en el tiempo de ejecución. El compilador conecta los nombres de clase resueltos en los archivos .class generados.
Las importaciones no importan en el nivel de bytecode, por lo que no debería haber diferencia de tiempo de ejecución.
Encuentro que es mejor: a) Ser explícito al enumerar todas las importaciones b) Deje que su IDE lo administre. Cualquiera de los principales IDE puede actualizar, ordenar y completar automáticamente sus importaciones.
He encontrado que a) es útil un par de veces al realizar reempaquetado manual fuera del contexto de una refactorización en IDE. Como por ejemplo, cuando la comercialización cambia el nombre de su producto y decide que todos sus paquetes cambien de nombre.
No hay un rendimiento ni un costo adicional para realizar la importación. * Frente a la importación de tipos específicos. Sin embargo, considero que es una buena práctica nunca usar importación. * Mi razón principal para esto es que me gusta mantener las cosas claras, claras y con la menor ambigüedad posible, y creo que con una. * Importación, pierdes eso .
Si está importando más de 20 clases del mismo paquete, es mejor que use la importación xxx. *. "Código limpio" está a favor de importar todo el paquete también.
Tiendo a usar lo que sea el IDE predeterminado. Encuentro que no es algo que realmente valga la pena preocuparse, ya que no tiene ningún impacto en el rendimiento, y la verificación de las dependencias se puede manejar con una variedad de herramientas.
Una buena razón para nunca usar import xxx. * Es tener una visión clara de las dependencies .
Puede saber más rápido que está utilizando una clase específica de otro paquete porque está enlistada al principio del archivo fuente.
Vista minoritaria: en mi código tiendo a usar toneladas de clases de algunos paquetes junto con algunas clases impares aquí y allá. Me gusta mantener mi lista de importaciones pequeña para poder decir lo que está pasando de un vistazo. Para hacer esto, configuré el umbral en 4 clases. Por encima de eso, Eclipse usará * para mi código. Encuentro que esto mantiene mis importaciones de paquetes legibles, y tiendo a referirme a ellas como lo primero que hago cuando miro una clase, para responder a la pregunta: ¿con quién habla?
En cuanto a la colisión de nombres: ¿Cuáles son las posibilidades de que importe cuatro o más clases de dos paquetes que tienen nombres de clase competidores? SI es más del 10% del tiempo, es posible que desee considerar la cantidad de paquetes en los que confía su clase (p. Ej., Refactorizarlos en clases más pequeñas).