Vor kurzem habe ich Sätze wie "Sie sollten niemals Wildcard-Importe verwenden" zu oft gehört. Also möchte ich die Community danach fragen. Sollten Wildcard-Importe wirklich nie in Java-Produktionscode verwendet werden, egal was? Gibt es Ausnahmen von dieser Regel? Ich habe Interesse an Ihrer persönlichen Erfahrung und Meinung. Verwenden Sie sie in Ihrem Produktionscode und würden Sie sie anderen empfehlen? Wie benutzt du sie - kannst du den besten Weg empfehlen, es zu machen?
Es ist auch interessant, es aus Scala Perspektive zu betrachten. Gilt das auch für Scala? Oder Wildcard-Importe in Scala sollten nur in Präsentationsfolien und SO-Antworten verwendet werden?
Wenn Sie sich beispielsweise die scalaz-Seite ansehen, empfehlen sie die Verwendung von Platzhalterimporten wie:
%Vor%Ich halte es auch für wichtig, implizite Konvertierungen zu berücksichtigen, die normalerweise mit Platzhaltern importiert werden.
In Scala sind Platzhalterimports ein Muss, da viele Bibliotheken erwarten, dass ihre impliziten Konvertierungen im Bereich liegen, aber sie werden nicht immer bequem benannt. Also,
%Vor%ist eine großartige Idee, während
%Vor%ist unglaublich peinlich. Besser noch, in Scala können Sie Ihre Importe in irgendeinen Bereich stellen:
%Vor%was wirklich dazu beiträgt, dass der Namespace in der ganzen Datei durcheinander bleibt. Und Sie können Teile des Imports selektiv umbenennen, von denen Sie wissen, dass sie einen Konflikt verursachen werden:
%Vor%Im Gegensatz dazu sind Sie in Java auf den globalen Gültigkeitsbereich für Importe beschränkt, und Sie können sie nicht umbenennen. Sie haben auch keine impliziten Conversions, daher ist es in Ordnung, nur die gesuchten Objekte einzubeziehen. Auf der anderen Seite haben Sie leistungsstarke IDE-Unterstützung, die Ihnen helfen wird, die gesuchte Klasse zu finden und genau für Sie zu importieren. Für Java gibt es also ein vernünftiges Argument, dass Sie Ihre IDE dazu bringen sollten, genau das einzubeziehen, was Sie brauchen, anstatt sich für alles zu entscheiden. Persönlich finde ich immer noch das zu peinlich und benutze die meiste Zeit nur Platzhalterimporte.
Nun, indem Sie vollständige Klassennamen angeben, entfernen Sie Mehrdeutigkeiten. Wenn Sie also explizit angeben, welche Klasse importiert werden soll, ist es viel einfacher, die Absicht des Codes zu verstehen. Java 1.2 kommt mir auch in den Sinn:
%Vor%Das hat in Java 1.1 gut funktioniert. In Java 1.2 wurde jedoch eine List-Schnittstelle zu java.util hinzugefügt, und der Code, der früher in Ordnung war, funktionierte nicht mehr. Viele Entwickler haben geweint.
In Java ist die Verwendung von Platzhaltern für den Import oder nicht hauptsächlich eine Frage der Wartbarkeit des Codes und der Bereitschaft, mit Importambiguitäten umzugehen (wenn zwei importierte Pakete Mitglieder mit denselben Namen haben). Auf der anderen Seite ist es aus ideologischer Sicht sehr sinnvoll, das gesamte Paket (zB java.sql._ ) zu importieren, wenn Sie ein konsistentes Verhalten wünschen und mehrere Zeilen von Importen aus demselben Paket vermeiden möchten.
Das meiste ist für Scala wahr, mit dem Unterschied:
import java.io.{File, FileInputStream} ; import java.lang.{Double=>JDouble} ; Alles in allem sollte die IMO-Wildcard-Import-Syntax in Scala nur für den Fall verwendet werden, wenn Sie mit einer bestimmten Bibliothek arbeiten und sich konsistent verhalten wollen (im Falle von Scalaz, um alle benötigten zu haben) Mitglieder, implizite Konvertierung, etc.).
Für die Java-Seite: Es ist absolut nichts Falsches daran, Wildcard-Importe zu verwenden! Zur Laufzeit gibt es keinen Leistungsmangel, da nur die Klassen geladen werden, die tatsächlich verwendet werden.
Der Importmechanismus von Java findet zur Kompilierzeit statt. Das einzige, für das es verwendet wird, ist, wenn Sie die Klasse Date zum Beispiel in Ihrem Code verwenden, es gibt keine Klasse Date im selben Paket, der Importmechanismus wird verwendet, um die Klasse Data in einer der import-Anweisungen zu finden .
Alles, was es tut, ist "herauszufinden, auf welche Klasse Sie verweisen". Nichts, was Ihre Laufzeitleistung ändern könnte.