Le but déroutant des constantes d'interface

En Java, il est possible de déclarer des champs dans une interface, les rendant implicitement publics, statiques et final. Cela a soulevé des questions parmi les développeurs.

Le piège de l'interface constante

Contrairement aux attentes, la définition de constantes au sein d'une interface est considérée comme un « anti-modèle d'interface constante ». Comme indiqué dans Effective Java de Joshua Bloch, cette pratique expose inutilement les détails de l'implémentation aux utilisateurs et entrave les futures modifications du code. De plus, il lie les sous-classes à l'interface constante.

Anomalies de plate-forme

Malgré cet avertissement, plusieurs interfaces constantes peuvent être trouvées dans la bibliothèque standard Java, comme Java. io.ObjectStreamConstants. Ces bizarreries ne doivent pas servir d'exemples mais plutôt de contrastes à éviter.

Approches alternatives

Pour éviter les pièges associés aux interfaces constantes, envisagez d'utiliser une classe d'utilitaire dédiée avec constructeurs privés et champs finaux statiques.

public final class Constants {

    private Constants() {}

    public static final double PI = 3.14159;
    public static final double PLANCK_CONSTANT = 6.62606896e-34;
}

Cette approche maintient les constantes privées tout en étant facilement accessibles via des importations statiques.

import static Constants.PLANCK_CONSTANT;
import static Constants.PI;

public class Calculations {

    public double getReducedPlanckConstant() {
        return PLANCK_CONSTANT / (2 * PI);
    }
}

Ainsi, même si les constantes d'interface peuvent sembler intrigantes, elles doivent être évitées en raison de défauts de conception potentiels. Utilisez plutôt des classes privées avec des finales statiques pour maintenir une base de code propre et flexible.