Uso de importación de comodines en Java y Scala

Question

Recientemente he escuchado declaraciones como "nunca se deben usar importaciones de comodines" con demasiada frecuencia. Entonces quiero preguntarle a la comunidad sobre esto. ¿Las importaciones de comodines realmente nunca deberían utilizarse en el código de producción de Java, no importa qué? ¿Hay excepciones a esta regla? Me interesa tu experiencia y opinión personal. ¿Los usas en tu código de producción y lo recomendarías a otros? ¿Cómo los usa? ¿Puede recomendar la mejor manera de hacerlo?

También es interesante mirarlo desde la perspectiva de Scala. Es lo mismo se aplica a Scala? ¿O las importaciones de comodines en Scala solo deberían usarse en diapositivas de presentación y respuestas de SO?

Si va a mirar a scalaz page, por ejemplo, recomiendan el uso de las importaciones como comodín:

import scalaz._ 
import Scalaz._ 

Creo que también es importante considerar las conversiones implícitas que normalmente se importan con comodines.

Answer 1

En Scala, las importaciones de comodines son obligatorias, ya que muchas bibliotecas esperan que sus conversiones implícitas estén dentro del alcance, pero no siempre tienen un nombre conveniente. Así,

import collection.JavaConversions._ 

es una gran idea, mientras que

import collection.JavaConversions.{asJavaConcurrentMap,enumerationAsScalaIterator,...} 

es muy incómodo. Mejor aún, en la Scala se puede poner sus importaciones en cualquier ámbito:

package mypackage { 
    class MyClass { 
    def myGraphicalWidgetHandler { 
     import java.awt._ 
     ... 
    } 
    ... 
    } 
    ... 
} 

que realmente ayuda a mantener el desorden espacio de nombres abajo a lo largo de todo el archivo. Y se puede cambiar el nombre selectivamente partes de la importación que sabe que entrar en conflicto:

import java.awt.{List => AwtList, _} 

Por el contrario, en Java, que está restringido a alcance global de las importaciones, y no se puede cambiar el nombre de ellos; tampoco tienes conversiones implícitas, por lo que está bien que solo selecciones esas cosas que estás buscando. Por otro lado, tiene una poderosa compatibilidad con IDE que le ayudará a encontrar la clase que está buscando e importarla solo para usted. Entonces, para Java, hay un argumento razonable que debe hacer para que su IDE obtenga justo lo que necesita en lugar de que decida tomarlo todo. Personalmente, yo aún encuentro esto demasiado incómodo y solo uso importaciones de comodines la mayor parte del tiempo.

Answer 2

Para el lado de Java: ¡No hay absolutamente nada de malo en usar importaciones de comodines! No hay falta de rendimiento en el tiempo de ejecución porque solo se cargan las clases que realmente se utilizan.

El mecanismo de importación de Java se lleva a cabo en tiempo de compilación. Para lo único que se usa es si usa la clase Date por ejemplo en su código y no hay clase Date en el mismo paquete, el mecanismo de importación se usará para encontrar los datos de clase en una de las declaraciones de importación.

Así que todo lo que hace es "averiguar a qué clase se refiere". Nada que pueda cambiar el rendimiento de tu tiempo de ejecución.

Answer 3

Bueno, al especificar nombres de clase completos, elimina la ambigüedad. Entonces, cuando declaras explícitamente qué clase importar, es mucho más fácil entender la intención del código. También me viene a la mente Java 1.2:

import java.util.*; 
import java.awt.*; 

... 
List blah; 

Esto funcionó bien en Java 1.1. Sin embargo, en Java 1.2 se agregó una interfaz de lista a java.util, y el código que solía estar bien ya no funcionaba. Muchos de los desarrolladores lloraron.

Answer 4

En Java, el uso de comodines para la importación o no es principalmente una cuestión de mantenimiento del código y [falta] de disposición para manejar ambigüedades de importación (cuando dos paquetes importados tienen miembros con los mismos nombres). Por otro lado, desde la perspectiva de la ideología, tiene mucho sentido importar todo el paquete (por ejemplo, java.sql._) si desea tener un comportamiento consistente y evitar las múltiples líneas de importación desde el mismo paquete.

La mayor parte de ella es fiel a Scala, con la diferencia de que:

1. Si desea importar varios miembros de la misma clase no contaminan el código y, al mismo tiempo, evitar posibles ambigüedades , Scala ofrece una sintaxis especial para eso: import java.io.{File, FileInputStream};
2. En Scala puede asignar alias a los miembros importados, para tratar las ambigüedades: import java.lang.{Double=>JDouble};
3. Como mencionaste correctamente, al usar una importación de comodines agregas implícitamente al contexto, lo que puede conducir a otro nivel de ambigüedades (por lo que esa es otra razón para pensar dos veces);

Así que, en definitiva, la OMI, la sintaxis de comodín en la importación Scala debe usarse sólo en el caso, cuando se trabaja con una biblioteca específica y quieren que actúe constantemente (en caso de Scalaz, tener todos los miembros requeridos, conversión implícita, etc. en su lugar).