À quoi servent les constantes d'interface?

J'apprends Java et je viens de découvrir que l'interface peut avoir des champs, qui sont publics statiques et définitifs. Je n'ai vu aucun exemple de ceux-ci jusqu'à présent. Quels sont certains des cas d'utilisation de ces constantes d'interface et puis-je en voir dans la bibliothèque standard Java?

Mettre des membres statiques dans une interface (et implémenter cette interface) est une mauvaise pratique et il y a même un nom pour cela, l' antipattern d'interface constante , voir Effective Java , Item 17:

Le modèle d'interface constant est une mauvaise utilisation des interfaces . Le fait qu'une classe utilise certaines constantes en interne est un détail d'implémentation. L'implémentation d'une interface constante entraîne la fuite de ce détail d'implémentation dans l'API exportée de la classe. Cela n'a aucune conséquence pour les utilisateurs d'une classe que la classe implémente une interface constante. En fait, cela peut même les confondre. Pire encore, cela représente un engagement: si dans une prochaine version la classe est modifiée pour ne plus avoir besoin d'utiliser les constantes, elle doit quand même implémenter l'interface pour assurer la compatibilité binaire. Si une classe non finale implémente une interface constante, toutes ses sous-classes verront leurs espaces de noms pollués par les constantes de l'interface.

Il existe plusieurs interfaces constantes dans les bibliothèques de la plateforme Java, telles que java.io.ObjectStreamConstants. Ces interfaces doivent être considérées comme des anomalies et ne doivent pas être émulées.

Pour éviter certains pièges de l'interface constante (car vous ne pouvez pas empêcher les gens de l'implémenter), une classe appropriée avec un constructeur privé doit être préférée (exemple emprunté à Wikipedia ):

public final class Constants {

    private Constants() {
        // restrict instantiation
    }

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

Et pour accéder aux constantes sans avoir à les qualifier complètement (c'est-à-dire sans avoir à les préfixer avec le nom de la classe), utilisez un import statique (depuis Java 5):

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

public class Calculations {

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

" Le modèle d'interface constant est une mauvaise utilisation des interfaces "

Quiconque a concocté cette hypothèse, quelque gourou qu'il soit, l'a concoctée sur la base de la nécessité de continuer à mettre en œuvre efficacement les mauvaises habitudes et pratiques. L'hypothèse est basée sur la promotion de la validité des mauvaises habitudes de conception de logiciels.

J'ai écrit une réfutation de réponse contre cette hypothèse ici: Quelle est la meilleure façon d'implémenter des constantes en Java? expliquant le caractère sans fondement de cette hypothèse.

Pendant 10 ans, cette question était restée ouverte, jusqu'à ce qu'elle soit close dans les 2 heures après que j'aie affiché mes raisons justifiant cette hypothèse, exposant ainsi la NON-Volonté de débattre de ceux qui s'accrochent à cette hypothèse erronée.

Ce sont les points que j'ai exprimés contre l'hypothèse

• La base de cette hypothèse est le besoin de méthodes et de règles RESTRICTIVES pour faire face aux effets des mauvaises habitudes et méthodologies logicielles.

• Les partisans du sentiment " Le modèle d'interface constant est une mauvaise utilisation des interfaces" sont incapables de fournir d'autres raisons que celles causées par la nécessité de faire face aux effets de ces mauvaises habitudes et pratiques.

• Résolvez le problème fondamental.

• Et puis pourquoi ne pas utiliser pleinement et exploiter toutes les fonctionnalités du langage de la structure du langage Java à votre convenance. Aucune veste requise. Pourquoi inventer des règles pour barricader votre mode de vie inefficace pour discriminer et incriminer des modes de vie plus efficaces?

La question fondamentale

est l'organisation de l'information. Les informations servant de médiateur au processus, et le comportement de ces informations doivent d'abord être compris, ainsi que les soi-disant règles métier - avant de concevoir ou de compléter des solutions au processus. Cette méthode d'organisation de l'information s'appelait il y a quelques décennies la normalisation des données.

Alors seule l'ingénierie d'une solution sera possible car aligner la granularité et la modularité des composants d'une solution avec la granularité et la modularité des composants de l'information est la stratégie optimale.

Il existe deux ou trois obstacles importants à l'organisation de l'information.

1. Le manque de perception de la nécessité d'une «normalisation» des modèles de données.

2. Les déclarations d'EF Codd sur la normalisation des données sont erronées, défectueuses et ambiguës.

3. La dernière mode qui se fait passer pour une ingénierie agile est la notion erronée selon laquelle il ne faut pas planifier et conditionner l'organisation des modules à l'avance, car vous pouvez la refactoriser au fur et à mesure. La refactorisation et le changement continu sans être entravés par de futures découvertes sont utilisés comme excuse. Les découvertes essentielles du comportement des informations de processus sont alors, en utilisant des astuces comptables pour retarder les profits et l'actifisation, c'est pourquoi les connaissances essentielles et leur traitement ne sont pas jugées nécessaires maintenant.

L'utilisation des constantes d'interface est une bonne pratique.

N'inventez pas de règles et n'émettez aucune fatwa contre cela simplement parce que vous aimez vos habitudes de programmation ponctuelles.

N'interdisez pas la possession d'armes à feu au motif qu'il y a des gens qui ne savent pas comment manier les armes ou qui sont enclins à abuser des armes à feu.

Si les règles que vous concoctez sont destinées à des novices en programmation incapables de coder professionnellement et que vous vous comptez parmi eux, dites-le - ne déclarez pas votre fatwa comme applicable à des modèles de données correctement normalisés.

Un raisonnement idiot - Les interfaces n'étaient pas destinées par les patrouilleurs du langage Java à être utilisées de cette façon?

Je me fiche de ce que les intentions originales des pères fondateurs avaient pour la Constitution américaine. Je me fiche des intentions non écrites et non codifiées. Je ne me soucie que de ce qui est littéralement codifié dans la Constitution écrite et de la manière dont je peux les exploiter pour le fonctionnement efficace de la société.

Je ne me soucie que de ce que me permettent les spécifications du langage / plate-forme Java et j'ai l'intention de les exploiter au maximum pour me donner un moyen d'exprimer mes solutions logicielles de manière efficace et efficiente. Aucune veste requise.

L'utilisation des constantes Enum est en fait une pratique horrible.

Il faut écrire du code supplémentaire pour mapper le paramètre à la valeur. Le fait que les fondateurs de Java n'aient pas fourni de mappage paramètre-valeur sans que vous ayez écrit ce code de mappage démontre que les constantes Enum sont tout aussi une utilisation non intentionnelle du langage Java.

D'autant que vous n'êtes pas encouragé à normaliser et à composant vos paramètres, il y aurait une fausse impression que les paramètres mélangés dans un sac Enum appartiennent à la même dimension.

Les constantes sont un contrat API

N'oublie pas ça. Si vous avez conçu et normalisé votre modèle de données et qu'il inclut des constantes, ces constantes sont des contrats. Si vous n'avez pas normalisé votre modèle de données, vous devez vous conformer aux fatwas données sur la façon de pratiquer le codage restrictif pour faire face à cette mauvaise habitude.

Par conséquent, les interfaces sont un moyen idéal de mettre en œuvre le contrat de Constants.

Une étrange présomption - Et si l'interface était implémentée par inadvertance.

Ouaip. N'importe qui pourrait implémenter par inadvertance une interface par inadvertance. Rien ne fera obstacle à de tels programmeurs par inadvertance.

Concevez et normalisez votre modèle de données contre les fuites

Ne placez pas de décrets restrictifs pour protéger les mauvaises pratiques présumées qui provoquent la fuite de paramètres non contractuels / errants dans l'API. Résolvez le problème fondamental, plutôt que de rejeter la faute sur les constantes d'interface.

Ne pas utiliser d'EDI est une mauvaise pratique

Un programmeur fonctionnant normalement et EFFICACE n'est pas là pour prouver combien de temps elle peut rester sous l'eau, jusqu'où elle pourrait marcher dans une chaleur fulgurante ou des orages humides. Elle doit utiliser un outil efficace comme une voiture ou un bus ou au moins un vélo pour prendre ses 10 miles au travail tous les jours.

Ne placez pas de restrictions sur les autres programmeurs simplement parce que vous avez une obsession d'ascèse ésotérique avec la programmation sans IDE.

Quelques frameworks sont conçus pour aider les programmeurs à continuer à pratiquer efficacement les mauvaises habitudes.

OSGI est un tel cadre. Tout comme le décret contre les constantes d'interface.

Par conséquent, la réponse définitive ...

Les constantes d'interface sont un moyen efficace et efficient de placer dans un contrat des composants bien conçus et normalisés d'un modèle de données.

Les constantes d'interface dans une interface privée correctement nommée imbriquée dans un fichier de classe sont également une bonne pratique pour regrouper toutes vos constantes privées plutôt que de les disperser dans le fichier.

Je suis tombé sur cette vieille question plusieurs fois maintenant et la réponse acceptée me confond toujours. Après beaucoup de réflexion, je pense que cette question peut être clarifiée davantage.

Pourquoi utiliser Interface Constant?

Comparez-les simplement:

public final class Constants {

    private Constants() {
        // restrict instantiation
    }

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

contre

public interface Constants {

    double PI = 3.14159;
    double PLANCK_CONSTANT = 6.62606896e-34;
}

Même usage. Beaucoup moins de code.

Mauvaise pratique?

Je pense que la réponse de @Pascal Thivent est mal soulignée, en voici ma version:

Mettre des membres statiques dans une interface ( et implémenter cette interface ) est une mauvaise pratique.

La citation de Effective Java suppose que l'interface constante est mise en œuvre par d'autres, ce qui, à mon avis, ne devrait pas (et ne se produira pas).

Lorsque vous créez une interface constante nommée quelque chose comme Constants, elle ne doit être implémentée par personne. (bien que techniquement possible, ce qui est le seul problème ici)

Cela n'arrivera pas dans la bibliothèque standard

La bibliothèque standard ne peut pas se permettre une éventuelle mauvaise utilisation de la conception, vous n'en verrez donc pas.

Cependant , pour les projets quotidiens des développeurs normaux, en utilisant l' interface de constantes est beaucoup plus facile parce que vous n'avez pas besoin de vous soucier static, final, empty constructor, etc., et il ne causera aucun problème de mauvaise conception. Le seul inconvénient auquel je peux penser est qu'il porte toujours le nom d '"interface", mais rien de plus.

Débat sans fin

À la fin, je pense que tout le monde ne fait que citer des livres et donner des opinions et des justifications à leurs positions. Aucune exception pour moi. Peut-être que la décision appartient encore aux développeurs de chaque projet. N'hésitez pas à l'utiliser si vous vous sentez à l'aise. Le mieux que nous puissions faire est de le rendre cohérent tout au long du projet .

Joshua Bloch, "Effective Java - Guide du langage de programmation":

Le modèle d'interface constant est une mauvaise utilisation des interfaces. Le fait qu'une classe utilise certaines constantes en interne est un détail d'implémentation. L'implémentation d'une interface constante entraîne la fuite de ce détail d'implémentation dans l'API exportée de la classe. Cela n'a aucune conséquence pour les utilisateurs d'une classe que la classe implémente une interface constante. En fait, cela peut même les confondre. Pire encore, cela représente un engagement: si dans une prochaine version la classe est modifiée pour ne plus avoir besoin d'utiliser les constantes, elle doit toujours implémenter l'interface pour assurer la compatibilité binaire. Si une classe non finale implémente une interface constante, toutes ses sous-classes verront leurs espaces de noms pollués par les constantes de l'interface.

Ils sont utiles si vous avez des constantes communes qui seront utilisées dans les classes qui implémentent l'interface.

Voici un exemple: http://www.javapractices.com/topic/TopicAction.do?Id=32

Mais notez que la pratique recommandée consiste à utiliser des importations statiques au lieu de constantes dans les interfaces. Voici une référence: http://www.javapractices.com/topic/TopicAction.do?Id=195

Il y a des réponses qui sont très raisonnables.

Mais j'ai quelques réflexions sur cette question. (peut être faux)

À mon avis, les champs dans une interface, ne doivent pas être des constantes pour l'ensemble du projet, ce ne sont que des moyens pour l'interface et les interfaces l'étendent et les classes qui implémentent ces interfaces ou ont une relation étroite avec elles. Ils doivent être utilisés dans une certaine plage non globale.

Deux points sur l'interface:

• Une interface décrit un sous-ensemble de ce qu'un objet qui l'implémente peut faire. (C'est l'intuition)

• Une interface décrit des constantes communes suivies d' objets qui l'implémentent.

  • Ces constantes communes sont destinées à être connues du client pour en savoir plus sur ces objets.
  • Donc, Constantes Interface est en effet contre-intuitif pour définir des constantes globales , puisque l'interface est utilisée pour décrire certains objets , pas tous les objets / aucun objet (considérez la signification de global ).

Donc, je pense que si l' interface des constantes n'est pas utilisée pour les constantes globales , alors c'est acceptable:

• Si ces constantes communes ont de bons noms, ils recommanderont à l'implémenteur de les utiliser (voir mon premier point pour l'exemple ci-dessous)
• Si une classe veut se synchroniser avec ces classes suivant la spécification, juste implementselle (et, bien sûr, utilisez ces constantes communes dans l'implémentation).

Exemple:

interface Drawable {

    double GOLDEN_RATIO = 1.618033988;
    double PI = 3.141592653;
    ...

    // methods
    ...
}

public class Circle implements Drawable {
    ...
    public double getCircumference() {
        return 2 * PI * r;
    }
}

void usage() {

    Circle circle = new Circle(radius: 3.0);
    double maxRadius = 5.0;

    if ( circle.getCircumference() < 2 * Circle.PI * maxRadius ) {
        ...
    }

}

Dans cet exemple:

• De Circle implements Drawable, vous savez immédiatement qu'il Circleest probablement conforme aux constantes définies dans Drawable, sinon ils doivent choisir un pire nom depuis les bons PIet GOLDEN_RATIOa déjà été pris!
• Seuls ces Drawableobjets sont conformes au spécifique PIet GOLDEN_RATIOdéfinis dans Drawable, il peut y avoir des objets qui ne sont pas Drawableavec une précision différente de pi et de nombre d'or.

L' javax.swing.SwingConstantsinterface est un exemple qui a des champs statiques qui sont utilisés parmi les classes swing. Cela vous permet d'utiliser facilement quelque chose comme

• this.add(LINE_START, swingcomponent);
• this.add(this.LINE_START, swingcomponent); ou
• this.add(SwingComponents.LINE_START, swingcomponent);

Cependant cette interface n'a pas de méthodes ...

Je suis tombé sur cette question et j'ai pensé ajouter quelque chose qui n'était pas mentionné. En général, je suis d'accord avec la réponse de Pascal ici . Cependant, je ne pense pas que les constantes sur une interface soient «toujours» un anti-modèle.

Par exemple, si les constantes que vous définissez font partie d'un contrat pour cette interface, je pense que l'interface est un endroit idéal pour les constantes. Dans certains cas, il n'est tout simplement pas approprié de valider vos paramètres en privé sans exposer le contrat aux utilisateurs de votre implémentation. Sans contrat public, les utilisateurs ne peuvent que deviner avec quoi vous validez, à moins de décompiler la classe et de lire votre code.

Donc, si vous implémentez une interface et que l'interface a les constantes que vous utilisez pour garantir vos contrats (comme des plages d'entiers par exemple), alors un utilisateur de votre classe peut être sûr qu'il utilise correctement l'instance d'interface en comparant les constantes dans l'interface se. Cela serait impossible si les constantes étaient privées pour votre implémentation ou si votre implémentation était un package privé ou quelque chose.

J'utilise des constantes d'interface lorsque je traite des constantes partagées entre les classes.

public interface TestConstants
{
    String RootLevelConstant1 = "RootLevelConstant1";

    interface SubGroup1
    {
        String SubGroupConstant1 = "SubGroup1Constant1";
        String SubGroupConstant2 = "SubGroup1Constant2";
    }

    interface SubGroup2
    {
        String SubGroupConstant1 = "SubGroup2Constant1";
        String SubGroupConstant2 = "SubGroup2Constant2";
    }
}

Le regroupement est un énorme atout, surtout avec un grand ensemble de constantes.

Pour les utiliser, il vous suffit de les enchaîner:

System.out.println(TestConstants.SubGroup1.SubGroupConstant1);
System.out.println(TestConstants.SubGroup2.SubGroupConstant1);
System.out.println(TestConstants.RootLevelConstant1);

Les champs doivent être déclarés dans une interface afin qu'ils soient plus faciles à partager et puissent être référencés sans introduire de couplage supplémentaire.

Source: Style de codage des outils de développement Java