Ce qui est une affaire de bon usage pour importation statique des méthodes ?

Question

Viens de recevoir un examen commentaire que mon statique de l'importation de la méthode n'était pas une bonne idée. La statique de l'importation a été d'une méthode à partir d'un DA de classe, qui a pour la plupart des méthodes statiques. Donc, dans le milieu de la logique métier, j'ai eu un da qui, apparemment, semblait appartenir à la classe actuelle:

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

L'examinateur n'a pas été tenu à ce que je change le code et je n'ai pas, mais je fais genre d'être d'accord avec lui. Une des raisons données pour ne pas statique-l'importation, elle était confuse où la méthode a été définie, il n'était pas dans la classe courante, et non pas dans un super-classe, donc trop peu de temps pour identifier sa définition (le web en fonction du système d'examen n'ont pas de liens cliquables comme IDE :-) je ne pense pas vraiment que ce questions de, la statique, les importations sont encore assez nouveau et bientôt nous serons tous d'obtenir utilisé pour localiser les.

Mais l'autre raison, la un je suis d'accord avec, c'est qu'un appel de méthode non qualifiés semble appartenir à l'objet courant et ne devrait pas sauter contextes. Mais si vraiment il faisait partie, il serait judicieux d'étendre cette super-classe.

Donc, quand n'est - il judicieux de statique des méthodes d'importation? Quand avez-vous fait? Avez/avez-vous aimé la façon dont les appels non qualifiés de look?

EDIT: L'opinion populaire semble être que la statique-méthodes d'importation si personne ne va confondre comme des méthodes de la classe en cours. Par exemple, les méthodes de java.lang.De mathématiques et de java.awt.Couleur. Mais si l'abs et getAlpha ne sont pas ambigus, je ne vois pas pourquoi readEmployee est. Comme dans beaucoup de choix de programmation, je pense que c'est aussi une question de préférence personnelle de la chose.

Merci pour vos réponse les gars, je suis la fermeture de la question.

Answer 1

C'est à partir du Soleil guide quand ils ont sorti la fonction (en italique dans l'original):

Donc, quand devez-vous utiliser statique d'importation? Très peu! Utiliser seulement quand vous feriez autrement être tenté de déclarer les copies locales des constantes, ou à l'abus de l'héritage (la Constante de l'Interface Antipattern). ... Si vous abusez de la statique de la fonction d'importation, il peut rendre votre programme illisible et difficile à maintenir, de polluer son espace de noms avec tous les membres statiques de l'importer. Les lecteurs de votre code (y compris vous-même, quelques mois après que vous l'avez écrit) ne connaîtront pas la classe d'un membre statique. L'importation de tous les membres statiques d'une classe peut être particulièrement préjudiciable à la lisibilité; si vous avez besoin de seulement un ou deux membres, de les importer individuellement.

(http://java.sun.com/j2se/1.5.0/docs/guide/language/static-import.html)

Il y a deux parties, je tiens à appeler spécifiquement:

• Utiliser des importations seulement quand vous étiez tentés de "l'abus de l'héritage". Dans ce cas, auriez-vous été tenté d'avoir BusinessObject extend some.package.DA? Si oui, statique, les importations peuvent être d'une façon plus propre de ce traitement. Si vous n'aurais jamais rêvé d'étendre some.package.DA, alors c'est probablement une mauvaise utilisation de la statique des importations. Ne pas l'utiliser juste pour économiser quelques caractères lors de la saisie.
• Importer des membres individuels. Dire import static some.package.DA.save au lieu de DA.*. Ce qui rend beaucoup plus facile de trouver où cette importés méthode est à venir.

Personnellement, j'ai utilisé cette fonctionnalité très rarement, et presque toujours uniquement avec des constantes ou des enums, jamais avec des méthodes. Le compromis, pour moi, n'est presque jamais la peine.

Answer 2

Une autre utilisation raisonnable de statique des importations est avec JUnit 4. Dans les versions antérieures de JUnit méthodes comme assertEquals et fail ont hérité depuis la classe de test étendu junit.framework.TestCase.

// old way
import junit.framework.TestCase;

public class MyTestClass extends TestCase {
    public void myMethodTest() {
        assertEquals("foo", "bar");
    }
}

Dans JUnit 4, classes de test n'est plus nécessaire d'étendre TestCase et peut, au lieu d'utiliser les annotations. Vous pouvez ensuite statiquement à l'importation de l'affirmer méthodes d' org.junit.Assert:

// new way
import static org.junit.Assert.assertEquals;

public class MyTestClass {
    @Test public void myMethodTest() {
        assertEquals("foo", "bar");
        // instead of
        Assert.assertEquals("foo", "bar");
    }
}

JUnit documents à l'aide de cette façon.

Answer 3

Efficace Java, Deuxième Édition, à la fin de l'Article 19, de notes que vous pouvez utiliser des importations si vous trouvez vous-même fortement à l'aide de constantes d'une classe utilitaire. Je pense que ce principe s'appliquerait aux statique les importations de ces deux constantes et des méthodes.

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();
    }
}

Cela a des avantages et des inconvénients. Elle rend le code un peu plus lisible, au détriment de la perte de certaines informations immédiates sur les cas où la méthode est définie. Cependant, une bonne IDE vous permettra d'aller à la définition, donc ce n'est pas vraiment un problème.

Vous devez l'utiliser avec parcimonie, et seulement si vous vous trouvez en utilisant des choses à partir du fichier importé un grand nombre de fois.

Edit: mis à Jour pour être plus précis, les méthodes, c'est ce que cette question fait référence. Le principe s'applique indépendamment de ce qui est importé (constantes ou méthodes).

Answer 4

Je suis d’accord qu’ils peuvent être problématiques d’un point de vue lisibilité et doivent être utilisés avec parcimonie. Mais lorsque vous utilisez une méthode statique commune, ils peuvent en fait augmenter la lisibilité. Par exemple, dans une classe de test JUnit, méthodes comme sont évidents d'où ils viennent. De même pour les méthodes de .

Answer 5

Je l’utilise pour la couleur beaucoup.

Il est très improbable que les couleurs seront confondre avec autre chose.