Warum ist die Verwendung eines Platzhalters in einer Java-Import-Anweisung schlecht?

Question

Es ist viel bequemer und sauberer, eine einzige Anweisung zu verwenden wie

import java.awt.*;

als eine Reihe von einzelnen Klassen zu importieren

import java.awt.Panel;
import java.awt.Graphics;
import java.awt.Canvas;
...

Was ist falsch an der Verwendung eines Platzhalters in der import Aussage?

Answer 1

Das einzige Problem dabei ist, dass Ihr lokaler Namespace dadurch überfüllt wird. Nehmen wir zum Beispiel an, Sie schreiben eine Swing-Anwendung und benötigen daher java.awt.Event und sind auch mit dem Kalendersystem des Unternehmens verbunden, das über com.mycompany.calendar.Event . Wenn Sie beides mit der Wildcard-Methode importieren, passiert eines der drei folgenden Dinge:

1. Sie haben einen eindeutigen Namenskonflikt zwischen java.awt.Event y com.mycompany.calendar.Event und kann daher nicht einmal kompiliert werden.
2. Sie schaffen es tatsächlich nur, einen zu importieren (nur einer Ihrer beiden Importe funktioniert .* ), aber es ist der falsche, und Sie haben Mühe herauszufinden, warum Ihr Code behauptet, dass der Typ falsch ist.
3. Wenn Sie Ihren Code kompilieren, gibt es keine com.mycompany.calendar.Event , aber wenn sie später eine hinzufügen, lässt sich Ihr zuvor gültiger Code plötzlich nicht mehr kompilieren.

Der Vorteil der expliziten Auflistung aller Importe besteht darin, dass ich auf einen Blick erkennen kann, welche Klasse Sie verwenden wollten, was das Lesen des Codes sehr viel einfacher macht. Wenn Sie nur eine schnelle, einmalige Sache machen, gibt es nichts explizit falsch aber künftige Betreuer werden Ihnen ansonsten für Ihre Klarheit danken.

Answer 2

Hier ist eine Abstimmung für Star-Importe. Eine Import-Anweisung ist dazu gedacht, eine Paket und nicht eine Klasse. Es ist viel sauberer, ganze Pakete zu importieren; die hier festgestellten Probleme (z. B. java.sql.Date gegen java.util.Date ) sind leicht durch andere Mittel zu beheben, nicht まったくもって die durch spezifische Importe angesprochen werden, und rechtfertigen sicherlich keine wahnsinnig pedantischen Importe für alle Klassen. Es gibt nichts Beunruhigenderes, als eine Quelldatei zu öffnen und 100 Importanweisungen durchblättern zu müssen.

Die Durchführung spezifischer Importe erschwert das Refactoring; wenn Sie eine Klasse entfernen/umbenennen, müssen Sie die alle seiner spezifischen Einfuhren. Wenn Sie eine Implementierung auf eine andere Klasse im selben Paket umstellen, müssen Sie die Importe korrigieren. Diese zusätzlichen Schritte können zwar automatisiert werden, aber sie sind wirklich ein Produktivitätsverlust ohne wirklichen Nutzen.

Wenn Eclipse standardmäßig keine spezifischen Klassenimporte durchführen würde, würde jeder immer noch Sternimporte durchführen. Es tut mir leid, aber es gibt wirklich keine rationale Rechtfertigung für spezifische Importe.

Hier erfahren Sie, wie Sie mit Klassenkonflikten umgehen können:

import java.sql.*;
import java.util.*;
import java.sql.Date;

Answer 3

Bitte lesen Sie meinen Artikel Import auf Abruf ist böse

Kurz gesagt, das größte Problem ist, dass Ihr Code abbrechen kann, wenn eine Klasse hinzugefügt. zu einem Paket, das Sie importieren. Zum Beispiel:

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

// ...

List list;

In Java 1.1 war dies in Ordnung; List wurde in java.awt gefunden und es gab keinen Konflikt.

Nehmen wir nun an, Sie checken Ihren perfekt funktionierenden Code ein, und ein Jahr später holt ihn jemand anderes heraus, um ihn zu bearbeiten, und verwendet Java 1.2.

Java 1.2 fügte eine Schnittstelle namens List zu java.util. BOOM! Ein Konflikt. Der perfekt funktionierende Code funktioniert nicht mehr.

Dies ist ein EVIL Sprachfunktion. Es gibt NO Grund, dass Code nicht mehr kompiliert werden sollte, nur weil ein Typ hinzugefügt. zu einem Paket...

Außerdem ist es für den Leser schwer zu erkennen, welches "Foo" Sie verwenden.

Answer 4

Es ist pas schlecht, um einen Platzhalter mit einer Java-Import-Anweisung zu verwenden.

Unter Sauberer Code Robert C. Martin empfiehlt sogar, sie zu verwenden, um lange Importlisten zu vermeiden.

Hier ist die Empfehlung:

J1: Vermeiden Sie lange Importlisten durch Verwendung von Wildcards

Wenn Sie zwei oder mehr Klassen aus einer Paket verwenden, dann importieren Sie das gesamte Paket mit

importieren Paket.*;

Lange Listen von Importen sind entmutigend für den Leser. Wir wollen nicht die den Kopf unserer Module mit 80 Zeilen Zeilen von Importen. Vielmehr wollen wir, dass die Importe eine prägnante Aussage darüber sein mit welchen Paketen wir zusammenarbeiten zusammenarbeiten.

Spezifische Einfuhren sind schwierig Abhängigkeiten, während Wildcard-Importe nicht sind. Wenn Sie eine Klasse spezifisch importieren Klasse importieren, dann muss diese Klasse existieren. Aber wenn Sie ein Paket mit einem Platzhalter importieren, müssen keine bestimmten Klassen existieren. Die import-Anweisung fügt einfach fügt das Paket dem Suchpfad hinzu wenn nach Namen gesucht wird. Es wird also keine echte Abhängigkeit durch solche Importe geschaffen, und sie dienen daher dazu, dass unsere Module weniger gekoppelt.

Es gibt Zeiten, in denen die lange Liste der bestimmter Einfuhren nützlich sein kann. Für zum Beispiel, wenn Sie sich mit Legacy-Code zu tun haben und herausfinden wollen welche Klassen Sie für Mocks und Stubs erstellen müssen, können Sie die Liste der spezifischen Importe durchgehen, um herauszufinden die echten qualifizierten Namen all dieser Klassen herausfinden und dann die entsprechenden Stubs einfügen. Allerdings ist diese Verwendung für spezifische Importe sehr selten. Außerdem werden die meisten modernen IDEs die Umwandlung der wildcarded Importe in eine Liste von spezifischen Importen mit einem einzigen Befehl. Also selbst im Legacy-Fall ist es besser zu importieren Wildcards zu importieren.

Wildcard-Importe können manchmal dazu führen, dass Namenskonflikte und Mehrdeutigkeiten verursachen. Zwei Klassen mit demselben Namen, aber in verschiedenen Paketen, müssen spezifisch importiert werden, oder zumindest spezifisch qualifiziert werden, wenn sie verwendet werden. Diese kann ein Ärgernis sein, ist aber selten genug dass die Verwendung von Platzhalterimporten immer noch im Allgemeinen besser ist als spezifische Importe.

Answer 5

Leistung : Keine Auswirkung auf die Leistung, da der Bytecode gleich ist. Allerdings wird es zu einem gewissen Kompilier-Overhead führen.

Zusammenstellung Auf meinem persönlichen Rechner dauert das Kompilieren einer leeren Klasse ohne Import 100 ms, aber dieselbe Klasse braucht 170 ms, wenn man java.* importiert.