Quelle est la meilleure façon d'implémenter les constantes en Java ?

Question

J'ai vu des exemples comme celui-ci :

public class MaxSeconds {
   public static final int MAX_SECONDS = 25;
}

et j'ai supposé que je pouvais avoir une classe Constants pour envelopper les constantes, en les déclarant static final. Je ne connais pratiquement rien à Java et je me demande si c'est la meilleure façon de créer des constantes.

Answer 1

J'utilise static final pour déclarer les constantes et utiliser la notation ALL_CAPS. J'ai vu un certain nombre de cas réels où toutes les constantes sont regroupées dans une interface. Quelques messages ont qualifié à juste titre cette pratique de mauvaise, principalement parce que ce n'est pas le but d'une interface. Une interface doit faire respecter un contrat et ne doit pas être un endroit où mettre des constantes sans rapport. Le fait de les rassembler dans une classe qui ne peut pas être instanciée (par le biais d'un constructeur privé) est également acceptable si la sémantique des constantes n'appartient pas à une ou plusieurs classes spécifiques. Je place toujours une constante dans la classe à laquelle elle est le plus liée, parce que cela a du sens et que c'est aussi plus facile à maintenir.

Les Enums sont un bon choix pour représenter une gamme de valeurs, mais si vous stockez des constantes autonomes en mettant l'accent sur la valeur absolue (par exemple, TIMEOUT = 100 ms), vous pouvez simplement opter pour l'attribut static final approche.

Answer 2

Je suis d'accord avec ce que la plupart des gens disent, il est préférable d'utiliser les enums lorsqu'il s'agit d'une collection de constantes. Cependant, si vous programmez sous Android, il existe une meilleure solution : Annotation IntDef .

@Retention(SOURCE)
@IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST,NAVIGATION_MODE_TABS})
public @interface NavigationMode {}
public static final int NAVIGATION_MODE_STANDARD = 0;
public static final int NAVIGATION_MODE_LIST = 1;
public static final int NAVIGATION_MODE_TABS = 2;
...
public abstract void setNavigationMode(@NavigationMode int mode);
@NavigationMode
public abstract int getNavigationMode();

L'annotation IntDef est supérieure aux enums d'une manière simple, elle prend beaucoup moins de place puisqu'il s'agit simplement d'un marqueur de compilation. Ce n'est pas une classe et elle n'a pas non plus la propriété de conversion automatique des chaînes de caractères.

Answer 3

Il est Mauvaise habitude et terriblement ennuyeuse pratique de citer Joshua Bloch sans comprendre la base du fondamentalisme zéro.

Je n'ai rien lu de Joshua Bloch, donc soit

• c'est un mauvais programmeur
• ou les personnes que j'ai trouvées jusqu'à présent le citant (Joshua est le nom d'un garçon, je présume) utilisent simplement son matériel comme scripts religieux pour justifier leurs indulgences religieuses logicielles.

Comme dans le fondamentalisme biblique, toutes les lois bibliques peuvent être résumées par

• Aimez l'identité fondamentale de tout votre cœur et de tout votre esprit.
• Aimez votre voisin comme vous-même

et ainsi de suite, le fondamentalisme de l'ingénierie logicielle peut être résumé par

• se consacrer aux fondamentaux de base avec toute la force et l'esprit de la programmation
• et consacrez-vous à l'excellence de vos collègues programmeurs comme vous le feriez pour vous-même.

De même, dans les milieux fondamentalistes bibliques, un corollaire fort et raisonnable est tiré

• Commencez par vous aimer vous-même. Car si vous ne vous aimez pas beaucoup, le concept "aime ton prochain comme toi-même" n'a pas beaucoup de poids, puisque "à quel point tu t'aimes toi-même" est la ligne de référence au-dessus de laquelle tu aimerais les autres.

De même, si vous ne vous respectez pas en tant que programmeur et que vous acceptez simplement les déclarations et les prophéties d'un gourou de la programmation SANS remettre en question les principes fondamentaux, vos citations et votre confiance en Joshua Bloch (et autres) n'ont aucun sens. Et par conséquent, vous n'avez aucun respect pour vos collègues programmeurs.

Les lois fondamentales de la programmation de logiciels

• la paresse est la vertu d'un bon programmeur
• vous devez rendre votre vie de programmeur aussi facile, aussi paresseuse et donc aussi efficace que possible
• vous devez rendre les conséquences et les entrailles de votre programmation aussi faciles, aussi paresseuses et donc aussi efficaces que possible pour vos voisins-programmeurs qui travaillent avec vous et ramassent les entrailles de votre programmation.

Les constantes d'interface sont une mauvaise habitude ? ??

Dans quelles lois de programmation fondamentalement efficace et responsable cet édit religieux s'inscrit-il ?

Je viens de lire l'article de wikipedia sur les constantes de modèle d'interface ( https://en.wikipedia.org/wiki/Constant_interface ), et les excuses stupides qu'il énonce contre les constantes des modèles d'interface.

• Pas d'IDE ? Qui sur terre, en tant que programmeur de logiciels, n'utiliserait pas un IDE ? La plupart d'entre nous sont des programmeurs qui préfèrent ne pas avoir à prouver leur survivalisme macho et ascétique en évitant l'utilisation d'un IDE.

  • Aussi - attendez une seconde les partisans de la programmation micro-fonctionnelle comme moyen de ne pas avoir besoin d'un IDE. Attendez de lire mon explication sur la normalisation des modèles de données.

• Pollue l'espace de nom avec des variables qui ne sont pas utilisées dans la portée actuelle ? Ce pourrait être les partisans de cette opinion

  • ne sont pas conscients de la nécessité de normaliser les modèles de données.

• Utiliser des interfaces pour imposer des constantes est un abus des interfaces. Les partisans de ce type d'utilisation ont la mauvaise habitude de

  • ne pas voir que les "constantes" doivent être traitées comme des contrats. Et les interfaces sont utilisées pour faire respecter ou projeter le respect d'un contrat.

• Il est difficile, voire impossible, de convertir les interfaces en classes implémentées à l'avenir. Hah .... hmmm ... ???

  • Pourquoi voudriez-vous vous engager dans un tel modèle de programmation comme moyen de subsistance permanent ? C'est-à-dire, pourquoi se consacrer à une habitude de programmation aussi AMBIVANTE et mauvaise ?

Quelles que soient les excuses, il n'existe AUCUNE EXCUSE VALABLE, lorsqu'il s'agit d'ingénierie logicielle fondamentalement efficace, pour délégitimer ou décourager de manière générale l'utilisation des constantes d'interface.

Peu importe les intentions initiales et l'état d'esprit des pères fondateurs qui ont rédigé la Constitution des États-Unis. Nous pourrions débattre des intentions originales des pères fondateurs, mais tout ce qui m'importe, ce sont les déclarations écrites de la Constitution américaine. Et il est de la responsabilité de chaque citoyen américain d'exploiter le fondamentalisme littéraire écrit, et non les intentions fondatrices non écrites, de la Constitution américaine.

De même, je ne me soucie pas des intentions "originales" des fondateurs de la plate-forme et du langage de programmation Java pour l'interface. Ce qui m'importe, ce sont les fonctionnalités efficaces que la spécification Java fournit, et j'ai l'intention d'exploiter ces fonctionnalités au maximum pour m'aider à respecter les lois fondamentales de la programmation responsable de logiciels. Je ne me soucie pas de savoir si je suis perçu comme "violant l'intention pour les interfaces". Je me moque de ce que Gosling ou quelqu'un de Bloch dit sur la "bonne façon d'utiliser Java", à moins que ce qu'ils disent ne viole pas mon besoin de remplir EFFECTIVEMENT les lois fondamentales.

La normalisation des modèles de données est fondamentale.

La façon dont votre modèle de données est hébergé ou transmis n'a pas d'importance. Que vous utilisiez des interfaces, des enums ou n'importe quoi d'autre, que vous soyez relationnel ou non, si vous ne comprenez pas la nécessité et le processus de normalisation du modèle de données.

Nous devons d'abord définir et normaliser le modèle de données d'un ensemble de processus. Et lorsque nous disposons d'un modèle de données cohérent, ce n'est qu'alors que nous pouvons utiliser le flux de processus de ses composants pour définir le comportement fonctionnel et les blocs de processus d'un domaine ou d'un champ d'applications. Et ce n'est qu'alors que nous pouvons définir l'API de chaque processus fonctionnel.

Même les facettes de la normalisation des données telles que proposées par EF Codd sont aujourd'hui sévèrement remises en question. Par exemple, sa déclaration sur 1NF a été critiquée comme étant ambiguë, mal alignée et trop simplifiée, tout comme le reste de ses déclarations, en particulier dans l'avènement des services de données modernes, de la technologie de repo et de la transmission. IMO, les déclarations EF Codd devraient être complètement abandonnées et un nouvel ensemble de déclarations plus plausibles mathématiquement devrait être conçu.

Un défaut flagrant d'EF Codd et la cause de son désalignement par rapport à une compréhension humaine efficace est sa croyance que les données multidimensionnelles et mutables perceptibles par l'homme peuvent être perçues efficacement par un ensemble de mappings bidimensionnels fragmentaires.

Les principes fondamentaux de la normalisation des données

Ce que EF Codd n'a pas réussi à exprimer.

Dans chaque modèle de données cohérent, il s'agit de l'ordre séquentiel gradué de la cohérence du modèle de données à atteindre.

1. L'unité et l'identité des instances de données.
   • concevoir la granularité de chaque composant de données, de sorte que leur granularité se situe à un niveau où chaque instance d'un composant peut être identifiée et récupérée de manière unique.
   • absence d'aliasing d'instance, c'est-à-dire qu'il n'existe aucun moyen par lequel une identification produit plus d'une instance d'un composant.
2. Absence de diaphonie d'instance. Il n'est pas nécessaire d'utiliser une ou plusieurs autres instances d'un composant pour contribuer à l'identification d'une instance d'un composant.
3. L'unité et l'identité des composants/dimensions des données.
   • Présence d'un déréglage des composants. Il doit exister une définition permettant d'identifier de manière unique un composant/dimension. Il s'agit de la définition primaire d'un composant ;
   • où la définition primaire n'aura pas pour effet d'exposer des sous-dimensions ou des membres-composants qui ne font pas partie d'un composant prévu ;
4. Une méthode unique de gestion des composants. Il ne doit exister qu'une, et une seule, définition du déphasage des composants pour un composant.
5. Il existe une, et une seule, interface de définition ou contrat pour identifier un composant parent dans une relation hiérarchique de composants.
6. Absence de diaphonie entre les composants. Il n'existe pas de nécessité d'utiliser un membre d'un autre composant pour contribuer à l'identification définitive d'un composant.
   • Dans une telle relation parent-enfant, la définition d'identification d'un parent ne doit pas dépendre d'une partie de l'ensemble des composants membres d'un enfant. Un composant membre de l'identité d'un parent doit être l'identité complète de l'enfant sans recourir à la référence d'un ou de tous les enfants d'un enfant.
7. Prévenir les apparitions bi-modales ou multi-modales d'un modèle de données.
   • Lorsqu'il existe deux définitions candidates d'un composant, c'est un signe évident qu'il existe deux modèles de données différents qui sont mélangés en un seul. Cela signifie qu'il y a une incohérence au niveau du modèle de données, ou au niveau du champ.
   • Un champ d'applications doit utiliser un et un seul modèle de données, de manière cohérente.
8. Détecter et identifier la mutation des composants. À moins que vous n'ayez effectué une analyse statistique des composants sur d'énormes données, vous ne voyez probablement pas, ou ne voyez pas la nécessité de traiter, la mutation des composants.
   • Un modèle de données peut voir certains de ses composants muter de manière cyclique ou progressive.
   • Le mode peut être la rotation des membres ou la rotation des transpositions.
   • La mutation par rotation des membres pourrait être un échange distinct de composants enfants entre composants. Ou alors, il faudrait définir des composants entièrement nouveaux.
   • La mutation transposition se manifeste par la transformation d'un membre dimensionnel en un attribut, et vice versa.
   • Chaque cycle de mutation doit être identifié comme une donnée-modale distincte.
9. Versionner chaque mutation. Ainsi, vous pouvez extraire une version précédente du modèle de données, lorsque le besoin se fait sentir de traiter une mutation du modèle de données vieille de 8 ans.

Dans un champ ou une grille d'applications de composants interservices, il doit y avoir un et un seul modèle de données cohérent ou il existe un moyen pour un modèle/une version de données de s'identifier.

Sommes-nous toujours en train de demander si nous pouvons utiliser des constantes d'interface ? Vraiment ?

Il y a des problèmes de normalisation des données en jeu qui sont plus importants que cette question banale. Si vous ne résolvez pas ces problèmes, la confusion que vous pensez que les constantes d'interface causent n'est comparativement rien. Rien du tout.

À partir de la normalisation du modèle de données, vous déterminez ensuite les composants comme variables, comme propriétés, comme constantes d'interface de contrat.

Ensuite, vous déterminez ce qui va dans l'injection de valeurs, le placement de la configuration des propriétés, les interfaces, les chaînes finales, etc.

Si vous devez utiliser l'excuse de la nécessité de localiser plus facilement un composant pour imposer des constantes d'interface, cela signifie que vous avez la mauvaise habitude de ne pas pratiquer la normalisation des modèles de données.

Vous souhaitez peut-être compiler le modèle de données dans une version vcs. Que vous puissiez sortir une version distinctement identifiable d'un modèle de données.

Les valeurs définies dans les interfaces sont totalement assurées d'être non mutables. Et partageables. Pourquoi charger un ensemble de chaînes finales dans votre classe depuis une autre classe quand tout ce dont vous avez besoin est cet ensemble de constantes ?

Alors pourquoi pas ceci pour publier un contrat de modèle de données ? Je veux dire que si vous pouvez le gérer et le normaliser de manière cohérente, pourquoi pas ? ...

public interface CustomerService {
  public interface Label{
    char AssignmentCharacter = ':';
    public interface Address{
      String Street = "Street";
      String Unit= "Unit/Suite";
      String Municipal = "City";
      String County = "County";
      String Provincial = "State";
      String PostalCode = "Zip"
    }

    public interface Person {
      public interface NameParts{
        String Given = "First/Given name"
        String Auxiliary = "Middle initial"
        String Family = "Last name"
      }
    }
  }
}

Maintenant, je peux faire référence aux étiquettes contractées de mes applications d'une manière telle que

CustomerService.Label.Address.Street
CustomerService.Label.Person.NameParts.Family

Cela confond le contenu du fichier jar ? En tant que programmeur Java, je ne me soucie pas de la structure du fichier jar.

Cela complique les échanges en cours d'exécution motivés par Osgi ? Osgi est un moyen extrêmement efficace pour permettre aux programmeurs de poursuivre leurs mauvaises habitudes. Il existe de meilleures alternatives qu'osgi.

Ou pourquoi pas ceci ? Il n'y a pas de fuite des constantes privées dans le contrat publié. Toutes les constantes privées devraient être regroupées dans une interface privée nommée "Constantes", car je ne veux pas avoir à chercher des constantes et je suis trop paresseux pour taper à plusieurs reprises "private final String".

public class PurchaseRequest {
  private interface Constants{
    String INTERESTINGName = "Interesting Name";
    String OFFICIALLanguage = "Official Language"
    int MAXNames = 9;
  }
}

Peut-être même ceci :

public interface PurchaseOrderConstants {
  public interface Properties{
    default String InterestingName(){
       return something();
    }
    String OFFICIALLanguage = "Official Language"
    int MAXNames = 9;
  }
}

Le seul problème avec les constantes d'interface qui mérite d'être pris en compte est celui de l'implémentation de l'interface.

Ce n'est pas "l'intention originale" des interfaces ? Comme si je me souciais de "l'intention originelle" des pères fondateurs lors de l'élaboration de la Constitution américaine, plutôt que de la manière dont la Cour suprême interpréterait les lettres écrites de la Constitution américaine ? ??

Après tout, je vis dans le pays de la liberté, de la nature et de la patrie des braves. Soyez courageux, soyez libres, soyez sauvages - utilisez l'interface. Si mes collègues programmeurs refusent d'utiliser des moyens de programmation efficaces et paresseux, suis-je obligé par la règle d'or de réduire mon efficacité de programmation pour m'aligner sur la leur ? Je devrais peut-être, mais ce n'est pas une situation idéale.