java tipo - Qual è un buon caso d'uso per l'importazione statica di metodi?




8 Answers

Questa è la guida di Sun quando hanno rilasciato la funzione (enfasi nell'originale):

Quindi quando dovresti usare l'importazione statica? Molto parsimonioso! Utilizzalo solo quando altrimenti saresti tentato di dichiarare copie locali di costanti o di abusare dell'ereditarietà (Constant Interface Antipattern). ... Se si abusa la funzionalità di importazione statica, può rendere il programma illeggibile e non gestibile, inquinando il suo spazio dei nomi con tutti i membri statici importati. I lettori del tuo codice (incluso te, pochi mesi dopo averlo scritto) non sapranno da quale classe proviene un membro statico. L'importazione di tutti i membri statici di una classe può essere particolarmente dannosa per la leggibilità; se è necessario solo uno o due membri, importarli singolarmente.

( https://docs.oracle.com/javase/8/docs/technotes/guides/language/static-import.html )

Ci sono due parti che voglio chiamare nello specifico:

  • Usa le importazioni statiche solo quando sei tentato di "abusare dell'ereditarietà". In questo caso, si sarebbe tentati di extend some.package.DA BusinessObject extend some.package.DA ? In tal caso, le importazioni statiche potrebbero essere un modo più pulito di gestirlo. Se non ti saresti mai sognato di estendere some.package.DA , probabilmente questo è un cattivo uso delle importazioni statiche. Non usarlo solo per salvare alcuni caratteri durante la digitazione.
  • Importa singoli membri. import static some.package.DA.save invece di DA.* . Ciò renderà molto più facile scoprire da dove proviene questo metodo importato.

Personalmente, ho usato questa caratteristica linguistica molto raramente, e quasi sempre solo con costanti o enumerazioni, mai con metodi. Il trade-off, per me, non vale quasi mai la pena.

ritorno comandi

Ho appena ricevuto un commento di recensione che la mia importazione statica del metodo non era una buona idea. L'importazione statica era di un metodo di una classe DA, che ha principalmente metodi statici. Così, nel mezzo della logica del business, ho avuto un'attività che apparentemente sembrava appartenere alla classe attuale:

import static some.package.DA.*;
class BusinessObject {
  void someMethod() {
    ....
    save(this);
  }
} 

Il revisore non era entusiasta di aver cambiato il codice e non l'ho fatto, ma sono in qualche modo d'accordo con lui. Una ragione fornita per l'importazione non statica è stata la confusione in cui è stato definito il metodo, non era nella classe corrente e non in nessuna superclasse, quindi anche un po 'di tempo per identificare la sua definizione (il sistema di revisione basato sul web non ha cliccabile link come IDE :-) Non penso che questo sia importante, le importazioni statiche sono ancora piuttosto nuove e presto ci abitueremo a localizzarle.

Ma l'altro motivo, quello su cui sono d'accordo, è che una chiamata di metodo non qualificata sembra appartenere all'oggetto corrente e non dovrebbe saltare contesti. Ma se appartenesse davvero, avrebbe senso estendere quella super classe.

Quindi, quando ha senso adottare metodi di importazione statici? Quando l'hai fatto? Ti è piaciuto / mi piace il modo in cui appaiono le chiamate non qualificate?

EDIT: L'opinione popolare sembra essere quella dei metodi di importazione statica se nessuno li confonderà come metodi della classe corrente. Ad esempio i metodi da java.lang.Math e java.awt.Color. Ma se abs e getAlpha non sono ambigui, non vedo perché readEmployee sia. Come in molte scelte di programmazione, penso che anche questa sia una preferenza personale.

Grazie per la vostra risposta ragazzi, sto chiudendo la domanda.




Efficace Java, Second Edition , alla fine dell'articolo 19 si nota che è possibile utilizzare le importazioni statiche se ci si trova pesantemente utilizzando le costanti da una classe di utilità. Penso che questo principio si applicherebbe alle importazioni statiche di costanti e metodi.

import static com.example.UtilityClassWithFrequentlyUsedMethods.myMethod;

public class MyClass {
    public void doSomething() {
        int foo= UtilityClassWithFrequentlyUsedMethods.myMethod();
        // can be written less verbosely as
        int bar = myMethod();
    }
}

Questo ha vantaggi e svantaggi. Rende il codice un po 'più leggibile a scapito della perdita di alcune informazioni immediate su dove è definito il metodo. Tuttavia, un buon IDE ti permetterà di andare alla definizione, quindi questo non è un grosso problema.

Dovresti comunque usarlo con parsimonia, e solo se ti ritrovi a usare cose del file importato molte, molte volte.

Modifica: aggiornato per essere più specifico dei metodi, poiché è a questo che si riferisce questa domanda. Il principio si applica indipendentemente da ciò che viene importato (costanti o metodi).




Sono d'accordo sul fatto che possono essere problematici dal punto di vista della leggibilità e dovrebbero essere usati con parsimonia. Ma quando si utilizza un metodo statico comune possono effettivamente aumentare la leggibilità. Ad esempio, in una classe di test JUnit, metodi come assertEquals sono ovvi da dove provengono. Allo stesso modo per i metodi di java.lang.Math .




Le importazioni statiche sono l'unica "nuova" caratteristica di Java che non ho mai usato e non intendo mai usare, a causa dei problemi che hai appena menzionato.




Sono utili per ridurre la verbosità, in particolare nei casi in cui vengono chiamati molti metodi importati e la distinzione tra metodi locali e importati è chiara.

Un esempio: codice che coinvolge più riferimenti a java.lang.Math

Un altro: una classe di builder XML in cui anteporre il nome di classe a ogni riferimento nascondeva la struttura che si stava costruendo




L'importazione statica IMO è piuttosto una bella funzionalità. È assolutamente vero che la forte dipendenza dall'importazione statica rende il codice illeggibile e difficile da capire a quale classe appartiene un metodo o attributo statico. Tuttavia, nella mia esperienza diventa una caratteristica utilizzabile specialmente quando si progettano classi Util che forniscono alcuni metodi e attributi statici. L'ambiguità che sorge ogni volta che si fornisce l'importazione statica può essere elusa stabilendo standard di codice. Nella mia esperienza all'interno di un'azienda questo approccio è accettabile e rende il codice più pulito e facile da capire. Preferibilmente inserisco il carattere _ in metodi statici frontali e attributi statici (in qualche modo adottati da C) . Apparentemente questo approccio viola gli standard di denominazione di Java, ma fornisce chiarezza al codice. Ad esempio, se abbiamo una classe AngleUtils:

public class AngleUtils {

    public static final float _ZERO = 0.0f;
    public static final float _PI   = 3.14f;

    public static float _angleDiff(float angle1, float angle2){

    }

    public static float _addAngle(float target, float dest){

    }
}

In questo caso l'importazione statica fornisce chiarezza e la struttura del codice mi sembra più elegante:

import static AngleUtils.*;

public class TestClass{

    public void testAngles(){

        float initialAngle = _ZERO;
        float angle1, angle2;
        _addAngle(angle1, angle2);
    }
}

Subito qualcuno può dire quale metodo o attributo proviene da un'importazione statica e nasconde le informazioni della classe a cui appartiene. Non suggerisco di utilizzare l'importazione statica per le classi che sono parte integrante di un modulo e di fornire metodi statici e non statici, poiché in questi casi è importante sapere quale classe fornisce determinate funzionalità statiche.




Devi usarli quando:

  • desideri utilizzare un'istruzione switch con valori enum
  • desideri rendere il tuo codice difficile da capire



Li uso quando potrò. Ho una configurazione IntelliJ per ricordarmi se dimentico. Penso che sia molto più pulito di un nome di pacchetto completo.




Related

java static-import