È molto più conveniente e più pulito usare una singola istruzione come
import java.awt.*;piuttosto che importare un gruppo di singole classi
import java.awt.Panel;
import java.awt.Graphics;
import java.awt.Canvas;
...
Cosa c'è di sbagliato nell'usare un carattere jolly importnell'istruzione?
Risposte:
L'unico problema è che ingombra il tuo spazio dei nomi locale. Ad esempio, supponiamo che tu stia scrivendo un'app Swing e che quindi sia necessario java.awt.Evente che tu stia anche interfacciando con il sistema di calendario dell'azienda, che ha com.mycompany.calendar.Event. Se si importano entrambi utilizzando il metodo jolly, si verifica una di queste tre cose:
java.awt.Evente com.mycompany.calendar.Event, quindi non puoi nemmeno compilare..*), ma è quella sbagliata e fai fatica a capire perché il tuo codice afferma che il tipo è sbagliato.com.mycompany.calendar.Event, ma quando successivamente ne aggiungono uno il tuo codice precedentemente valido interrompe improvvisamente la compilazione.Il vantaggio di elencare esplicitamente tutte le importazioni è che posso dire a colpo d'occhio quale classe intendevi utilizzare, il che rende semplicemente molto più semplice la lettura del codice. Se stai semplicemente facendo una cosa una tantum, non c'è nulla di esplicitamente sbagliato , ma i futuri manutentori ti ringrazieranno per la tua chiarezza altrimenti.
Ecco un voto per le importazioni di stelle. Una dichiarazione di importazione ha lo scopo di importare un pacchetto , non una classe. È molto più pulito importare interi pacchetti; i problemi qui identificati (ad es. java.sql.Datevs java.util.Date) sono facilmente risolti con altri mezzi, non realmente affrontati da importazioni specifiche e certamente non giustificano importazioni follemente pedanti su tutte le classi. Non c'è nulla di più sconcertante che aprire un file sorgente e dover scorrere tra 100 istruzioni di importazione.
Effettuare importazioni specifiche rende più difficile il refactoring; se rimuovi / rinomina una classe, devi rimuovere tutte le sue importazioni specifiche. Se si passa un'implementazione a un'altra classe nello stesso pacchetto, è necessario correggere le importazioni. Mentre questi passaggi aggiuntivi possono essere automatizzati, sono in realtà un aumento della produttività senza alcun guadagno reale.
Anche se Eclipse non eseguisse l'importazione di classe per impostazione predefinita, tutti continuerebbero comunque a importare stelle. Mi dispiace, ma non esiste davvero alcuna giustificazione razionale per effettuare importazioni specifiche.
Ecco come affrontare i conflitti di classe:
import java.sql.*;
import java.util.*;
import java.sql.Date;
Foo, e se leggo il tuo codice senza usare un IDE (poiché il tuo argomento è che non dovrei usarne uno), come faccio a sapere da quale pacchetto Fooproviene ? Certo, usando un IDE, l'IDE me lo dirà, ma il tuo intero argomento è che dovrei essere in grado di leggere il codice senza uno. Fare importazioni esplicite aiuta a documentare il codice (ottimo motivo per evitare i caratteri jolly) , ed è molto più probabile che leggerò il codice senza usare un IDE, piuttosto che scriverò il codice senza usare un IDE.
per favore, vedi il mio articolo Import on Demand is Evil
In breve, il problema più grande è che il tuo codice può rompersi quando una classe viene aggiunta a un pacchetto importato. Per esempio:
import java.awt.*;
import java.util.*;
// ...
List list;
In Java 1.1, questo andava bene; L'elenco è stato trovato in java.awt e non si sono verificati conflitti.
Supponiamo ora di controllare il tuo codice perfettamente funzionante, e un anno dopo qualcun altro lo fa uscire per modificarlo e sta usando Java 1.2.
Java 1.2 ha aggiunto un'interfaccia denominata Elenco a java.util. BOOM! Conflitto. Il codice perfettamente funzionante non funziona più.
Questa è una funzione del linguaggio MALE . Non vi è alcun motivo per cui il codice dovrebbe interrompere la compilazione solo perché un tipo viene aggiunto a un pacchetto ...
Inoltre, rende difficile per un lettore determinare quale "Foo" stai usando.
java.util.Listvs java.awt.Listnon è poi così male da capire, ma provalo quando il nome della classe è Configuratione più librerie di dipendenze l'hanno aggiunto nella loro ultima versione repo di maven.
E ' non è male usare una wild card con una dichiarazione di importazione Java.
In Clean Code , Robert C. Martin in realtà consiglia di usarli per evitare lunghi elenchi di importazione.
Ecco la raccomandazione:
J1: evitare elenchi di importazione lunghi utilizzando i caratteri jolly
Se si utilizzano due o più classi da un pacchetto, importare l'intero pacchetto con
pacchetto di importazione. *;
Lunghi elenchi di importazioni sono scoraggianti per il lettore. Non vogliamo ingombrare le parti superiori dei nostri moduli con 80 linee di importazione. Piuttosto vogliamo che le importazioni siano una dichiarazione concisa su quali pacchetti collaboriamo.
Le importazioni specifiche sono forti dipendenze, mentre le importazioni con caratteri jolly non lo sono. Se si importa specificamente una classe, tale classe deve esistere. Ma se si importa un pacchetto con un carattere jolly, non è necessario che esistano classi particolari. L'istruzione import aggiunge semplicemente il pacchetto al percorso di ricerca durante la ricerca di nomi. Quindi nessuna vera dipendenza viene creata da tali importazioni e servono quindi a mantenere i nostri moduli meno accoppiati.
Ci sono momenti in cui il lungo elenco di importazioni specifiche può essere utile. Ad esempio, se hai a che fare con il codice legacy e vuoi scoprire per quali classi hai bisogno di creare mock e stub, puoi scorrere l'elenco delle importazioni specifiche per scoprire i veri nomi qualificati di tutte quelle classi e poi mettere gli stub appropriati in atto. Tuttavia, questo uso per importazioni specifiche è molto raro. Inoltre, la maggior parte degli IDE moderni ti consentirà di convertire le importazioni con caratteri jolly in un elenco di importazioni specifiche con un singolo comando. Quindi, anche nel caso legacy, è meglio importare i caratteri jolly.
Le importazioni di caratteri jolly possono talvolta causare conflitti di nomi e ambiguità. Due classi con lo stesso nome, ma in pacchetti diversi, dovranno essere importate in modo specifico, o almeno specificatamente qualificate quando utilizzate. Questo può essere un fastidio, ma è abbastanza raro che l'utilizzo delle importazioni con caratteri jolly sia generalmente migliore delle importazioni specifiche.
Prestazioni : nessun impatto sulle prestazioni poiché il codice byte è lo stesso. sebbene porterà ad alcune spese generali di compilazione.
Compilazione : sulla mia macchina personale, la compilazione di una classe vuota senza importare nulla richiede 100 ms ma la stessa classe quando importa java. * Richiede 170 ms.
import java.*non importa nulla. Perché dovrebbe fare la differenza?
Ingombra il tuo spazio dei nomi, richiedendo di specificare completamente tutti i nomi di classe che sono ambigui. L'evento più comune di questo è con:
import java.util.*;
import java.awt.*;
...
List blah; // Ambiguous, needs to be qualified.
Aiuta anche a rendere concrete le tue dipendenze, poiché tutte le dipendenze sono elencate nella parte superiore del file.
La maggior parte dei posti in cui ho lavorato che utilizzano una quantità significativa di Java rendono le importazioni esplicite parte dello standard di codifica. A volte uso ancora * per la prototipazione rapida e quindi espando gli elenchi di importazione (alcuni IDE lo faranno anche per te) durante la produzione del codice.
In un precedente progetto ho scoperto che il passaggio da * -import a importazioni specifiche ha ridotto della metà il tempo di compilazione (da circa 10 minuti a circa 5 minuti). * -Import consente al compilatore di cercare ciascuno dei pacchetti elencati per una classe corrispondente a quella utilizzata. Mentre questa volta può essere piccolo, si aggiunge a grandi progetti.
Un effetto collaterale dell'importazione * era che gli sviluppatori avrebbero copiato e incollato le linee di importazione comuni anziché pensare a ciò di cui avevano bisogno.
Nel libro DDD
In qualsiasi tecnologia di sviluppo su cui si baserà l'implementazione, cerca modi per ridurre al minimo il lavoro di refactoring MODULES. In Java, non c'è scampo dall'importazione in singole classi, ma puoi almeno importare interi pacchetti alla volta, riflettendo l'intenzione che i pacchetti siano unità altamente coesive riducendo allo stesso tempo lo sforzo di cambiare i nomi dei pacchetti.
E se ingombra lo spazio dei nomi locale non è colpa tua - incolpare la dimensione del pacchetto.
Non vi è alcun impatto sul runtime, poiché il compilatore sostituisce automaticamente * con nomi di classe concreti. Se decompilassi il file .class, non lo vedresti mai import ...*.
C # usa sempre * (implicitamente) poiché puoi solo il usingnome del pacchetto. Non puoi mai specificare il nome della classe. Java introduce la funzione dopo c #. (Java è così complicato sotto molti aspetti ma va oltre questo argomento).
In Intellij Idea quando "organizzi le importazioni", sostituisce automaticamente più importazioni dello stesso pacchetto con *. Questa è una funzione obbligatoria in quanto non è possibile disattivarla (sebbene sia possibile aumentare la soglia).
Il caso elencato dalla risposta accettata non è valido. Senza * hai ancora lo stesso problema. Devi specificare il nome della pakcage nel tuo codice, indipendentemente dal fatto che tu * usi o meno.
Per la cronaca: quando aggiungi un'importazione, indichi anche le tue dipendenze.
Si potrebbe vedere rapidamente quali sono le dipendenze dei file (escluse le classi dello stesso spazio dei nomi).
Il più importante è che l'importazione java.awt.*può rendere il programma incompatibile con una futura versione di Java:
Supponiamo che tu abbia una classe chiamata "ABC", stai usando JDK 8 e importi java.util.*. Supponiamo ora che Java 9 esca e che abbia una nuova classe nel pacchetto java.utilche per coincidenza viene anche chiamata "ABC". Il tuo programma ora non verrà compilato su Java 9, perché il compilatore non sa se con il nome "ABC" intendi la tua classe o la nuova classe in java.awt.
Non avrai questo problema quando importi solo quelle classi esplicitamente da java.awtquelle che usi effettivamente.
risorse:
Streamcome esempio di una nuova classe aggiunta in Java in java.util in Java 8 ...
Tra tutti i punti validi fatti da entrambe le parti non ho trovato il motivo principale per evitare il carattere jolly: mi piace essere in grado di leggere il codice e sapere direttamente qual è ogni classe, o se la sua definizione non è nella lingua o il file, dove trovarlo. Se viene importato più di un pacchetto con *, devo cercare ciascuno di essi per trovare una classe che non riconosco. La leggibilità è suprema e sono d'accordo che il codice non dovrebbe richiedere un IDE per leggerlo.