Slide "Don't be too lazy!"





  • Hallo Herr Goik,

    ich habe mit einem Bekannten, der Software-Entwickler ist, über diese Folie gesprochen, weil mir die Begründung gefehlt hat. Er meinte daraufhin, dass Robert C. Martin, ein Pionier der Software-Entwicklung, sich in seinem Werk "Clean Code" vielmehr für die hier als schlecht dargestellte Variante ausgesprochen hat:

    98bd14c7-c8c1-440d-9cfd-75388b699fe6-image.png

    Daher würde ich mich für eine Erläuterung zu dieser Folie interessieren.

    Viele Grüße!
    Lena Körner



  • Hallo Frau Körner,

    ich fange mal an mit:

    We don't want to clutter up ...

    Das ist meiner Meinung nach ein schwaches Argument. Die Logik von Anweisungen sollte im Vordergrund stehen, nicht ihre
    textuelle Darstellung. Softwareentwicklung erfolgt so gut wie immer unter Nutzung von Entwicklungsumgebungen (IDEs).
    Diese haben z.B. die Möglichkeit, Serien von Imports aus einem identischen Package »zusammenzufalten«, wie etwa in
    folgendem Faksimile:

    + import package ...
    

    Im genannten Beispiel würde ein Klick auf das »+« Symbol die Liste importierter Klassen bei Bedarf öffnen. IntelliJ
    Idea bietet dieses Feature, allerdings nur für die Gesamtheit aller Imports, nicht für individuelle Klassen /
    Interface Gruppen.

    Mal ganz abgesehen davon, dass die Verwendung des expliziten Schlüsselworts package im Beispielcode fragwürdig ist.

    So no true dependency is created

    Wie bitte? Es gibt zwei Fälle:

    1. Die durch die import package.*; Anweisung definierte Menge von Klassen und Interfaces wird im nachfolgenden Code gar nicht genutzt. Dann gibt es keine Abhängigkeiten, die Anweisung ist vollständig überflüssig und der Compiler quittiert dies mit einer Unused import statement Warnung.

    2. Mindestens eine Klasse oder Interface aus der Menge wird verwendet. Dann gibt es genau die Abhängigkeiten, welche der Menge ersatzweise notwendiger expliziter import package.X; Anweisungen entsprechen. Mit dem Unterschied, dass selbige bei Verwendung der expliziten Form auch explizit sichtbar sind.

    Wildcard imports can sometimes cause name conflicts ...

    Das sieht dann in der Realität beispielsweise so aus:

    import java.awt.*;
    import java.util.*;
    
    // ...
    
    List list;
    

    Obiger Code ließ sich bis Java 1.1 (Achtung: Grobstaubalarm!) übersetzen. Es gab bis dahin lediglich java.awt.List.

    In Java 1.2 wurde java.util.List neu eingeführt. Damit führt obiger Code zu einem Reference to 'List' is ambiguous, both 'java.awt.List' and 'java.util.List' match compile time error. Anders gesagt: Sie bezahlen die »Syntactic sugar« Bequemlichkeit mit der Notwendigkeit, bei jedem JDK Version oder auch Fremdbibliothek Upgrade resultierende Fehler zu beseitigen. Bereits übersetzter Code bleibt davon glücklicherweise unberührt. Fairerweise sei angemerkt, dass dies die bei weitem harmlosere Problemkategorie im Kontext von (insbesondere JRE!) Version Upgrades darstellt.

    Meine persönliche Meinung: Beide Varianten haben Tradeoffs, siehe auch den Argumentaustausch in Why using a wild card with a Java import statement bad?. Zumindest die bei MI verwendete Idea IDE implementiert einen Kompromiss: Ab 5 Klassen/Interfaces aus demselben Package wird automatisch die import .../* Variante gewählt, wobei der voreingestellte Wert 5 frei konfigurierbar ist.

    Die Debatte hat sich insofern entspannt, als man in einer IDE nur über einen Datentyp zu »hovern« braucht, um das zugehörige Package zu sehen. Kaum jemand durchforstet für diese Suche noch import Anweisungen. Dies ist nur noch für eine Minderheit Texteditor fixierter Puristen interessant.

    Gruß Martin Goik


Log in to reply