Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
importiert man eigentlich eher jede Komponente selbst, oder nutzt man .* Importe? Was ist vom Stil her besser? Bzw welche Vor-/Nachteile hat man dadurch?
Bei ner GUI hab ich zb schnell >20 javax.swing.XXX;
Ab wann kann man sagen, dass ein javax.awt.*; oder javax.swing.*; Sinn macht?
Hmm, ich denke mal, dass es sinnvoller ist, alles voll auszuschreiben, das beugt merkwürdigen Situationen im Stile "Wo kommt diese Klasse jetzt her ?" vor. Da das sowieso von Eclipse/NetBeans/etc automatisch übernommen wird, ist es auch kein Mehraufwand.
Wenn du gleichnamige Klassen in unterschiedlichen packages hast, dann musst du zwangsläufig auf wildcard imports verzichten, weil der Compiler ja dann nicht weiß welche Klasse du meinst.
Beispielsweise die Klasse List ist im package java.util und java.awt package vorhanden.
wenn du beide packages importierst brauchst du zwangsläufig noch einen direkten import für die Klasse list, z.b. java.util.List.
Wenn du imports per Hand organisierst, dann solltest du immer direkte imports verwenden.
Direkt machen sie IMHO fast nur Sinn, wenn man sie NICHT per hand verwaltet, weil man da of neue hinzufügen und alte entfernen muss. Die modernen IDEs machen's einem da ja leicht: Man schreibt erstmal
import javax.swing.*;
hin, kann dann rumbasteln, und am Ende mit Strg+Shift+O alles glattziehen lassen.
Direkt machen sie IMHO fast nur Sinn, wenn man sie NICHT per hand verwaltet, weil man da of neue hinzufügen und alte entfernen muss. Die modernen IDEs machen's einem da ja leicht: Man schreibt erstmal
import javax.swing.*;
hin, kann dann rumbasteln, und am Ende mit Strg+Shift+O alles glattziehen lassen.
Auch wenns nicht gerade zum Thema passt: Eclipse räumt auch bei static imports auf, und das nervt! Da kann man die Variablen/Methoden erst nachträglich in der Kurzform schreiben. Ich verwende die bei der Arbeit, wo wir teilweise meiner Meinung nach zu lange Klassen- und Membernamen schreiben.
Es gibt durchaus Fälle, in denen die Sternchen-Variante vorzuziehen ist. Und zwar wenn man sich mal überlegt, dass Java auf Sprachebene außer Klassen und Packages ja nicht viel an Möglichkeiten zur Strukturierung bietet. Mal ein stark vereinfachtes Beispiel: du hast 2 Module A und B, wobei A von B abhängig ist. In dem Fall hat
den wichtigen Vorteil, dass es das dahinter stehende Konzept besser kommuniziert, nämlich dass ein Modul insgesamt von einem anderen Modul abhängt, und nicht nur von einer Menge von Klassen.
Importe schaut sich doch eh keiner an, da drückt das imho nicht viel aus ???:L
Zumindest bei mir sind die zumeist entweder zugeklappt oder werden zumindest überscrollt und nur selten beachtet.
Schließe mich hier Cola_Colin an. Die import Anweisungen sind maximal dann interessant, wenn man gerade ein Tutorial im Internet liest. Um Abghänigkeiten zu erkennen, bietet mir die IDE wesentlich mehr und bequemere Lösungen an, als sich durch die imports zu wühlen.
Gut, solche Überlegungen haben was mit der Nachvollziehbarkeit und der Bindung von Fachmodellen und Code-Artefakten zu tun. Wenn du sowas (noch) nicht verstehst, heißt das aber noch lange nicht, dass das "eh keiner" macht.
Auszug aus dem Javabuch von Guido Krüger hat gesagt.:
Im Gegensatz zu ähnlichen Konstrukten in anderen Sprachen ist die Verwendung der wildcard Variante der import-Anweisung nicht zwangsläufig ineffizienter. In der Sprachspezifikation wird sie als "type import on demand" bezeichnet, was bedeutet, dass die Klasse erst dann in den angegebenen Paketen gesucht wird, wenn das Programm sie wirklich benötigt. Keinesfalls muss der Compiler beim Parsen der import-Anweisung zwangsläufig alle Klassendateien des angegebenen Pakets in den Hauptspeicher laden oder ähnlich zeit- und speicheraufwändige Dinge machen. Es schadet also im allgemeinen nichts, die wildcard Variante der import-Anweisung zu verwenden. (geringfügig geändert, weil im Original von erster und zweiter variante die rede war)
Fazit: Import-Anweisungen dienen dazu, den eigentlichen Quelltext lesbarer zu machen. Importe ohne Wildcard (heisst nicht, dass man nicht auch ohne gleichnamige User programmieren kann XD) machen den Quelltext dagegen schon wieder viel unübersichtlicher, z.B. dann, wenn man ihn in einem Forum wie diesem hier posten will. Dadurch entstehende Doppelimporte (z.B. List) werden von der IDE ohnehin angezeigt, aber erst, wenn man eine der in Frage kommenden Klassen verwenden will. Dann kann man aber durchaus noch die gewünschte Klasse zusätzlich explizit importieren. Die jeweils anderen Klassen können dann auch noch mit ihrem vollqualifizierten Namen verwendet werden. Also ich zumindest verfahre in Eclipse immer so, dass mir die IDE sagen darf, was importiert werden muß, jedoch kürze ich mir zwischendurch die vorgeschlagnen Anweisungen insbesondere "import static" immer mal gerne mit Wildcards zurecht.
Übrigens, auch in Martin, "Clean Code", S. 307 und Evans, "Domain-Driven Design", S. 112 wird auf die Problematik von spezifischen Imports eingegangen.
Von "das interessiert noch eh keinen" kann also nun wahrlich keine Rede sein. Dies und Äußerungen wie "das macht doch eh die IDE" zeugen nun nicht gerade von Weitblick.
Es gibt durchaus Fälle, in denen die Sternchen-Variante vorzuziehen ist. Und zwar wenn man sich mal überlegt, dass Java auf Sprachebene außer Klassen und Packages ja nicht viel an Möglichkeiten zur Strukturierung bietet. Mal ein stark vereinfachtes Beispiel: du hast 2 Module A und B, wobei A von B abhängig ist. In dem Fall hat
den wichtigen Vorteil, dass es das dahinter stehende Konzept besser kommuniziert, nämlich dass ein Modul insgesamt von einem anderen Modul abhängt, und nicht nur von einer Menge von Klassen.
Vielleicht stehe ich noch auf dem Schlauch (ist ja noch früh), aber ein [c]import xyz.b.Foo;[/c] ist spezifischer als ein [c]import xyz.b.*;[/c], wie kann etwas spezifischeres weniger Informationen enthalten als etwas allgemeineres?
Abgesehen davon bin ich der Meinung, dass der Quelltext eine Abstraktionsstufe zu niedrig ist für solche Informationen (Modulabhängigkeiten), dafür gibt es Buildtools mit Dependencymanagement und Modulsysteme welche Abhängigkeiten zur Laufzeit deklarieren, mit Maven zB. steht in der Pom explizit welche abhängigkeiten es zwischen den Artifakten gibt.
Bei OSGi ist es ähnlich, das Manifest legt die Abhängigkeiten fest, auch wieder an einem zentralen Ort.
Übrigens, auch in Martin, "Clean Code", S. 307 und Evans, "Domain-Driven Design", S. 112 wird auf die Problematik von spezifischen Imports eingegangen.
Es wäre schön wenn du uns verraten würdest was da genau steht, selbst wenn wir alle die Bücher haben (ich find sie sehr gut übrigens), würde es der Diskussion helfen.
Kannst du mir bitte sagen, wo man das in Eclipse einstellen kann? Leider habe ich diese Option nicht gefunden und laufend habe ich unused imports weil ich es oft vergesse zu machen
Kannst du mir bitte sagen, wo man das in Eclipse einstellen kann? Leider habe ich diese Option nicht gefunden und laufend habe ich unused imports weil ich es oft vergesse zu machen
Window->Preferences:
In dem Baum:
Java->Editor->Save Actions
dann rechts "Additional actions" aktivieren und den [c]Configure...[/c] Button drücken. Dort kannst du einiges Einstellen.
Vielleicht stehe ich noch auf dem Schlauch (ist ja noch früh), aber ein [c]import xyz.b.Foo;[/c] ist spezifischer als ein [c]import xyz.b.*;[/c], wie kann etwas spezifischeres weniger Informationen enthalten als etwas allgemeineres?
Bitte lies meinen Beitrag noch mal. Die Aussage, die ich im Code ausdrücken will ist "Modul A ist von Modul B abhängig". Und um die Nachvollziehbarkeit dieser Aussage geht es. Im Kontext dieser Idee, die dem Code-lesenden Menschen vermittelt werden soll, ist
Code:
import xyz.b.Foo;
schlichtweg was ganz, ganz anderes, nämlich "A ist von einer bestimmten Klass Foo abhängig".
Abgesehen davon bin ich der Meinung, dass der Quelltext eine Abstraktionsstufe zu niedrig ist für solche Informationen (Modulabhängigkeiten), dafür gibt es Buildtools mit Dependencymanagement und Modulsysteme welche Abhängigkeiten zur Laufzeit deklarieren, mit Maven zB. steht in der Pom explizit welche abhängigkeiten es zwischen den Artifakten gibt.
Für die obersten Schichten stimme ich dir zu (nutze selbst auch den Maven-Multi-Module-Kram für die höhere Strukturierung). Aber diese kannst du halt nur ziemlich weit oben ansetzen. Für jedes noch so kleine Modul ein Maven-Module zu erstellen wäre ein ziemlicher Rückschritt was Refactorings und die Wartbarkeit deines Projekts angeht. Damit bist du dann ziemlich schnell wieder an der Stelle, an der du mit dem, was dir die Sprache bereitstellt, den Rest des Weges gehen musst (soll heißen, die sinnvolle Aufteilung des Codes auf den mittleren bis unteren Ebenen).
Es wäre schön wenn du uns verraten würdest was da genau steht, selbst wenn wir alle die Bücher haben (ich find sie sehr gut übrigens), würde es der Diskussion helfen.
Beide raten in verschiedenen Kontexten davon ab. Evans schreibt in Bezug auf die Modularisierung
"True, this technique means mixing two scales (classes depend on packages), but it communicates more than the previous voluminous list of classes—it conveys the intent to create a dependency on particular modules."
Wie man sieht mit dem Einwand, dass man in Java nur Klassen als "A" nehmen kann. Obige Aussage wird also durch die Einschränkungen der Sprache zu "Klasse X (in Modul A) ist von Modul B abhängig"
Martin hingegen bezieht sich eher auf die Verringerung von harten Abhängigkeiten.
Bitte lies meinen Beitrag noch mal. Die Aussage, die ich im Code ausdrücken will ist "Modul A ist von Modul B abhängig". Und um die Nachvollziehbarkeit dieser Aussage geht es. Im Kontext dieser Idee, die dem Code-lesenden Menschen vermittelt werden soll, ist
Code:
import xyz.b.Foo;
schlichtweg was ganz, ganz anderes, nämlich "A ist von einer bestimmten Klass Foo abhängig".
Gut, semantisch ist es natürlich ein Unterschied, ob der Code ausdrückt, Klasse X in Modul A ist komplett von Modul B abhängig.
Für mich persönlich ist der marginal, muss zugeben, ich lese regelmässig auch keine import statements (gibt ja mittlerweile mehr Möglichkeiten Kopplung und Kohäsion darzustellen als "nur" im Code direkt).
Aber wenn ich das tue, dann sehe ich persönlich die Abhängigkeiten schon auf Modulebene (Packageebene).
Für die obersten Schichten stimme ich dir zu (nutze selbst auch den Maven-Multi-Module-Kram für die höhere Strukturierung). Aber diese kannst du halt nur ziemlich weit oben ansetzen. Für jedes noch so kleine Modul ein Maven-Module zu erstellen wäre ein ziemlicher Rückschritt was Refactorings und die Wartbarkeit deines Projekts angeht.
Sicherlich übertrieben, Maven Module sind eben keine Java Module (= Packages).
Damit bist du dann ziemlich schnell wieder an der Stelle, an der du mit dem, was dir die Sprache bereitstellt, den Rest des Weges gehen musst (soll heißen, die sinnvolle Aufteilung des Codes auf den mittleren bis unteren Ebenen).
Schon klar, aber wie gesagt, es gibt heute sehr viele Möglichkeiten Abhängigkeiten darzustellen.
Beide raten in verschiedenen Kontexten davon ab. Evans schreibt in Bezug auf die Modularisierung
Wie man sieht mit dem Einwand, dass man in Java nur Klassen als "A" nehmen kann. Obige Aussage wird also durch die Einschränkungen der Sprache zu "Klasse X (in Modul A) ist von Modul B abhängig"
Eric will einerseits (natürlich) den Code ausdrucksfähiger machen, was ich noch einsehe, andererseits den Aufwand fürs Refactoring reduzieren, letzteres Argument ist heute allerdings nicht mehr gültig imho, dank IDE gestütztem Refactoring.
Martin hingegen bezieht sich eher auf die Verringerung von harten Abhängigkeiten.
Martins Argumentation geht in die Richtung, dass eine konkrete Klasse zu importieren eine "härtere Anhangigkeit" wäre als ein ganzes Package/Modul, was ich nachvollziehen kann.
Aber in plain Java ist es nunmal so, dass ich nur ausdrücken kann "Klasse X in Modul A ist abhängig von Modul B"
oder "Klasse X in Modul A ist abhängig von Klasse Y in Modul B", ich kann nicht direkt im Code ausdrücken "Modul A ist abhängig von Modul B", erst OSGi schliesst diese Lücke, aber eben nicht im Code, sondern im Manifest, und da gehört es auch besser hin (Abstraktionsebene).
Man sollte aber auch die Kehrseite beleuchten:
Fügt jemand in Modul B eine Klasse hinzu die den gleichen Namen hat wie eine von Modul A auf Modulebene (import *) importierte Klasse, bricht der Code, sollte selten sein, aber nicht unmöglich.
Auch gibt Eric zu, dass da verschiedene Abstraktionsstufen gemischt werden.
Interessante Diskussion imho, ist doch nicht so eindeutig das ganze wie ich zuerst dachte nur weil IDEs heute viel können
Übrigens, auch in Martin, "Clean Code", S. 307 und Evans, "Domain-Driven Design", S. 112 wird auf die Problematik von spezifischen Imports eingegangen.
Von "das interessiert noch eh keinen" kann also nun wahrlich keine Rede sein. Dies und Äußerungen wie "das macht doch eh die IDE" zeugen nun nicht gerade von Weitblick.
Mal in Clean Code nachgelesen... dort steht, dass die wildcard aus zwei Gründen besser ist:
1.) Weniger clutter am Anfang der Klasse
2.) Weniger starke Abhängigkeit von anderen Modulen, da nicht einzelne Klassen direkt eingebunden werden.
Ganz zustimmmen möchte ich da aber trotzdem nicht. 1.) ist einfach egal, wenn Eclipse die importe automatisch zusammenfaltet. Klar, wenn man mal in der Situation ist, nur einen Texteditor zu haben ist die wildcard übersichtlicher, aber wann hat man das schon ?
2.) ist schon eher ein Grund, wobei ich hier der Meinung bin, dass es dafür bessere Tools gibt, als direkt in die importe zu schauen.
Nun, im Endeffekt verwende ich die importe bewusst eigentlich gar nicht, von daher ist es für mich wohl egal, wie Eclipse mir das nun zusammenschnipselt
Über was diskutiert ihr hier eigentlich? Schlussendlich gibts die Imports nicht, um irgendwelche Module abzubilden, sondern weil man dann zum Glück nicht bei jeder Benutzung jeder Klasse den vollen Namen (d.h. mit Package) schreiben muss. Wer irgendwas aus diesen Package-Deklarationen lesen will, macht IMHO etwas falsch.
Schlussendlich gibts die Imports nicht, um irgendwelche Module abzubilden, sondern weil man dann zum Glück nicht bei jeder Benutzung jeder Klasse den vollen Namen (d.h. mit Package) schreiben muss.
Sprechen wir aneinander vorbei?
Der Grund, warum Imports existieren, ist - aus technischer Sicht - der von mir genannte. Ich interpretiere von dieser Diskussion, dass ihr mehr Informationen aus diesen Packagedeklarationen gewinnen wollt.
Ich denke aber, dass ihr eher vielleicht mit der Packagestruktur unzufrieden seid? Aber da könnte ich auch nur Maven o.ä. nennen