Java Language Pitfall - Les importations de Wildcard peuvent rendre votre code fragile


Exemple

Prenons l'exemple partiel suivant:

import com.example.somelib.*;
import com.acme.otherlib.*;

public class Test {
    private Context x = new Context();   // from com.example.somelib
    ...
}

Supposons que lorsque vous avez développé le code pour la première fois avec la version 1.0 de somelib et la version 1.0 de otherlib . Ensuite, vous devrez mettre à niveau vos dépendances vers des versions ultérieures et décider d’utiliser otherlib version 2.0. Supposons également que l'une des modifications apportées à otherlib entre 1.0 et 2.0 consistait à ajouter une classe de Context .

Maintenant, lorsque vous recompilez Test , vous obtenez une erreur de compilation indiquant que le Context est une importation ambiguë.

Si vous êtes familier avec la base de code, cela représente probablement un inconvénient mineur. Sinon, vous avez du travail à faire pour résoudre ce problème, ici et potentiellement ailleurs.

Le problème ici est les importations de caractères génériques. D'une part, l'utilisation de caractères génériques peut rendre vos cours plus courts. D'autre part:

  • Des modifications compatibles vers le haut vers d'autres parties de votre base de code, vers des bibliothèques standard Java ou vers des bibliothèques tierces peuvent entraîner des erreurs de compilation.

  • La lisibilité en souffre. À moins d'utiliser un IDE, il peut être difficile de déterminer les importations de caractères génériques dans une classe nommée.

La leçon est que c'est une mauvaise idée d'utiliser des importations de caractères génériques dans un code qui doit durer longtemps. Les importations spécifiques (non génériques) ne nécessitent pas beaucoup d'efforts si vous utilisez un IDE, et l'effort en vaut la peine.