Quelle est la meilleure façon d'implémenter des constantes en Java? [fermé]

Je déconseillerais fortement d'avoir une seule classe de constantes. Cela peut sembler une bonne idée à l'époque, mais lorsque les développeurs refusent de documenter les constantes et que la classe se développe pour englober plus de 500 constantes qui ne sont toutes pas liées les unes aux autres (étant liées à des aspects entièrement différents de l'application), cela se transforme généralement en le fichier de constantes étant complètement illisible. Au lieu de cela:

• Si vous avez accès à Java 5+, utilisez enums pour définir votre constantes pour une zone d'application. Toutes les parties de la zone d'application doivent se référer aux énumérations, et non aux valeurs constantes, pour ces constantes. Vous pouvez déclarer une énumération similaire à la façon dont vous déclarez une classe. Les énumérations sont peut-être la fonctionnalité la plus (et, sans doute, la seule) utile de Java 5+.
• Si vous avez des constantes qui ne sont valides que pour une classe particulière ou l'une de ses sous-classes, déclarez-les comme protégées ou publiques et placez-les dans la classe supérieure de la hiérarchie. De cette façon, les sous-classes peuvent accédez à ces valeurs constantes (et si d'autres classes y accèdent via public, les constantes ne sont pas uniquement valides pour une classe particulière...ce qui signifie que les classes externes utilisant cette constante peuvent être trop étroitement couplées à la classe contenant la constante)
• Si vous avez une interface avec un comportement défini, mais que les valeurs renvoyées ou les valeurs d'argument doivent être particulières, il est parfaitement acceptable de définir des constantes sur cette interface afin que d'autres implémenteurs y aient accès. Cependant, évitez de créer une interface juste pour contenir des constantes: elle peut devenir aussi mauvaise qu'une classe créée juste pour contenir des constantes.

C'est une MAUVAISE PRATIQUEd'utiliser des interfaces juste pour contenir des constantes (nommé constant interface pattern par Josh Bloch). Voici ce que Josh conseille:

Si les constantes sont fortement liées à une classe ou une interface existante, vous devrait les ajouter à la classe ou interface. Par exemple, tous les classes primitives numériques en boîte, comme Entier et Double, exportation Constantes MIN_VALUE et MAX_VALUE. Si les constantes sont mieux considérées comme les membres d'une type énuméré, vous devrait les exporter avec un enum type. Sinon, vous devez exporter le constantes avec un non instanciable classe utilitaire.

Exemple:

// Constant utility class
package com.effectivejava.science;
public class PhysicalConstants {
    private PhysicalConstants() { }  // Prevents instantiation

    public static final double AVOGADROS_NUMBER   = 6.02214199e23;
    public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
    public static final double ELECTRON_MASS      = 9.10938188e-31;
}

A propos de la convention de nommage:

Par convention, ces champs ont des noms composé de lettres majuscules, avec mots séparés par des traits de soulignement. Il est critique que ces champs contiennent primitives de valeurs ou de références pour des objets immuables.

Dans Effective Java (2nd edition), il est recommandé d'utiliser enums au lieu d'ints statiques pour les constantes.

Il y a un bon writeup sur enums en Java ici: http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

Notez qu'à la fin de cet article, la question posée est:

Alors, quand devriez-vous utiliser enums?

, Avec une réponse de:

Chaque fois que vous avez besoin d'un ensemble fixe de constantes

Évitez simplement d'utiliser une interface:

public interface MyConstants {
    String CONSTANT_ONE = "foo";
}

public class NeddsConstant implements MyConstants {

}

C'est tentant, mais viole l'encapsulation et brouille la distinction des définitions de classe.

J'utilise l'approche suivante:

public final class Constants {
  public final class File {
    public static final int MIN_ROWS = 1;
    public static final int MAX_ROWS = 1000;

    private File() {}
  }

  public final class DB {
    public static final String name = "oups";

    public final class Connection {
      public static final String URL = "jdbc:tra-ta-ta";
      public static final String USER = "testUser";
      public static final String PASSWORD = "testPassword";

      private Connection() {}
    }

    private DB() {}
  }

  private Constants() {}
}

Que, par exemple, j'utilise Constants.DB.Connection.URL pour obtenir constante. Il semble plus "objet orienté" comme pour moi.

La création de constantes finales statiques dans une classe distincte peut vous causer des problèmes. Le compilateur Java va réellement optimiser cela et placer la valeur réelle de la constante dans n'importe quelle classe qui la référence.

Si vous modifiez plus tard la classe 'Constantes' et que vous ne faites pas de recompilation difficile sur d'autres classes qui font référence à cette classe, vous vous retrouverez avec une combinaison d'anciennes et de nouvelles valeurs utilisées.

Au lieu de les considérer comme des constantes, considérez-les comme une configuration les paramètres et créer une classe pour gérer. Demandez aux valeurs d'être non finales et envisagez même d'utiliser des getters. À l'avenir, lorsque vous déterminerez que certains de ces paramètres devraient être configurables par l'utilisateur ou l'administrateur, ce sera beaucoup plus facile à faire.

L'erreur numéro un que vous pouvez faire est de créer une classe accessible globalement appelée avec un nom générique, comme des Constantes. Cela devient simplement jonché d'ordures et vous perdez toute capacité à comprendre quelle partie de votre système utilise ces constantes.

Au lieu de cela, les constantes devraient aller dans la classe qui les "possède". Avez-vous une constante appelée TIMEOUT? Il devrait probablement aller dans votre classe Communications () ou Connection (). MAX_BAD_LOGINS_PER_HOUR? Va dans User (). Et ainsi de suite et ainsi de suite.

L'autre utilisation possible est Java .fichiers de propriétés lorsque les "constantes" peuvent être définies au moment de l'exécution, mais pas facilement modifiables par l'utilisateur. Vous pouvez le paquet de ces dans votre .jars et référencez-les avec la classe ResourceLoader.

C'est la bonne voie à suivre.

Généralement, les constantes sont et non conservées dans des classes de "Constantes" distinctes car elles ne sont pas détectables. Si la constante est pertinente pour la classe actuelle, les garder là aide le prochain développeur.

Qu'en est-il d'une énumération?

Je préfère utiliser des getters plutôt que des constantes. Ces getters peuvent renvoyer des valeurs constantes, par exemple public int getMaxConnections() {return 10;}, mais tout ce qui a besoin de la constante passera par un getter.

Un avantage est que si votre programme dépasse la constante-vous trouvez qu'il doit être configurable-vous pouvez simplement changer la façon dont le getter renvoie la constante.

L'autre avantage est que pour modifier la constante, vous n'avez pas besoin de recompiler tout ce qui l'utilise. Lorsque vous référencez un statique champ final, la valeur de cette constante est compilée dans n'importe quel bytecode qui la référence.

Je suis d'accord que l'utilisation d'une interface n'est pas la voie à suivre. Éviter ce modèle a même son propre élément (#18) dans Bloch Effective Java.

Un argument de Bloch contre le modèle d'interface constante est que l'utilisation de constantes est un détail d'implémentation, mais l'implémentation d'une interface pour les utiliser expose ce détail d'implémentation dans votre API exportée.

Le modèle public|private static final TYPE NAME = VALUE; est un bon moyen de déclarer une constante. Personnellement, je pense qu'il vaut mieux éviter de faire un classe séparée pour abriter toutes vos constantes, mais je n'ai jamais vu de raison de ne pas le faire, autre que la préférence personnelle et le style.

Si vos constantes peuvent être bien modélisées en tant qu'énumération, considérez la structure enum disponible en 1.5 ou version ultérieure.

Si vous utilisez une version antérieure à 1.5, vous pouvez toujours supprimer les énumérations typesafe en utilisant des classes Java normales. (Voir ce site pour plus d'informations à ce sujet).

Sur la base des commentaires ci-dessus, je pense que c'est une bonne approche pour changer la classe constante globale à l'ancienne (ayant des variables finales statiques publiques) en son équivalent enum d'une manière comme ceci:

public class Constants {

    private Constants() {
        throw new AssertionError();
    }

    public interface ConstantType {}

    public enum StringConstant implements ConstantType {
        DB_HOST("localhost");
        // other String constants come here

        private String value;
        private StringConstant(String value) {
            this.value = value;
        }
        public String value() {
            return value;
        }
    }

    public enum IntConstant implements ConstantType {
        DB_PORT(3128), 
        MAX_PAGE_SIZE(100);
        // other int constants come here

        private int value;
        private IntConstant(int value) {
            this.value = value;
        }
        public int value() {
            return value;
        }
    }

    public enum SimpleConstant implements ConstantType {
        STATE_INIT,
        STATE_START,
        STATE_END;
    }

}

Alors je peux les référer à comme:

Constants.StringConstant.DB_HOST

Une bonne conception orientée objet ne devrait pas avoir besoin de nombreuses constantes accessibles au public. La plupart des constantes doivent être encapsulées dans la classe qui en a besoin pour faire son travail.

Il y a un certain nombre d'opinions pour répondre à cela. Pour commencer, les constantes en java sont généralement déclarées publiques, statiques et finales. Voici les raisons:

public, so that they are accessible from everywhere
static, so that they can be accessed without any instance. Since they are constants it
  makes little sense to duplicate them for every object.
final, since they should not be allowed to change

Je n'utiliserais jamais une interface pour un accesseur/objet de CONSTANTES simplement parce que les interfaces devraient généralement être implémentées. Cela n'aurait-il pas l'air drôle:

String myConstant = IMyInterface.CONSTANTX;

Au lieu de cela, je choisirais entre quelques façons différentes, basées sur de petits compromis, et cela dépend donc de ce que vous besoin:

1.  Use a regular enum with a default/private constructor. Most people would define 
     constants this way, IMHO.
  - drawback: cannot effectively Javadoc each constant member
  - advantage: var members are implicitly public, static, and final
  - advantage: type-safe
  - provides "a limited constructor" in a special way that only takes args which match
     predefined 'public static final' keys, thus limiting what you can pass to the
     constructor

2.  Use a altered enum WITHOUT a constructor, having all variables defined with 
     prefixed 'public static final' .
  - looks funny just having a floating semi-colon in the code
  - advantage: you can JavaDoc each variable with an explanation
  - drawback: you still have to put explicit 'public static final' before each variable
  - drawback: not type-safe
  - no 'limited constructor'

3.  Use a Class with a private constructor:
  - advantage: you can JavaDoc each variable with an explanation
  - drawback: you have to put explicit 'public static final' before each variable
  - you have the option of having a constructor to create an instance
     of the class if you want to provide additional functions related
     to your constants 
     (or just keep the constructor private)
  - drawback: not type-safe

4. Using interface:
  - advantage: you can JavaDoc each variable with an explanation
  - advantage: var members are implicitly 'public static final'
  - you are able to define default interface methods if you want to provide additional
     functions related to your constants (only if you implement the interface)
  - drawback: not type-safe

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

Une approche que nous devrions vraiment éviter : utiliser des interfaces pour définir des constantes.

Créer une interface spécifiquement pour déclarer des constantes est vraiment la pire chose : cela va à l'encontre de la raison pour laquelle les interfaces ont été conçues : définir le contrat de méthode(s).

Même si une interface existe déjà pour répondre à un besoin spécifique, déclarer les constantes en elles ne font vraiment pas sense as constantes ne devrait pas faire partie de l'API et du contrat fourni aux classes client.

Pour simplifier, nous avons globalement 4 approches valides .

Avec static final String/Integer champ :

• 1) en utilisant une classe qui déclare des constantes à l'intérieur mais pas seulement.
• 1 variant) création d'une classe dédiée à déclarer uniquement les constantes.

Avec Java 5 enum :

• 2) déclarer l'énumération dans une classe de but connexe (donc en tant qu'imbriqué classe).
• 2 variant) créant l'énumération en tant que classe autonome (ainsi définie dans son propre fichier de classe).

TLDR: Quel est le meilleur moyen et où localiser les constantes ?

Dans la plupart des cas, la voie enum est probablement plus fine que la static final String/Integer way et personnellement je pense que la voie static final String/Integer ne devrait être utilisée que si nous avons de bonnes raisons de ne pas utiliser d'énumérations.
Et à propos de l'endroit où nous devrions déclarer les valeurs constantes, l'idée est de rechercher s'il existe une seule classe existante qui possède une cohésion fonctionnelle spécifique et forte avec des valeurs constantes. Si nous trouvons une telle classe, nous devrions l'utiliser comme constantes titulaire. Sinon, la constante ne doit être associée à aucune classe particulière.

static final String/ static final Integer rapport enum

L'utilisation des énumérations est vraiment un moyen de fortement considéré.
Les énumérations ont un grand avantage sur String ou Integer champ constant.
Ils ont mis un plus contrainte de compilation. Si vous définissez une méthode qui prend l'énumération comme paramètre, vous ne pouvez passer qu'une valeur d'énumération définie dans la classe enum(ou null).
Avec String et Integer vous pouvez les remplacer par toutes les valeurs de type compatible et la compilation ira bien même si la valeur n'est pas une constante définie dans le static final String/ static final Integer champs.

Par exemple, en dessous de deux constantes définies dans une classe comme static final String champs:

public class MyClass{

   public static final String ONE_CONSTANT = "value";
   public static final String ANOTHER_CONSTANT = "other value";
   . . .
}

Voici une méthode qui s'attend à avoir l'un de ces constantes comme paramètre:

public void process(String constantExpected){
    ...    
}

Vous pouvez l'invoquer de cette façon:

process(MyClass.ONE_CONSTANT);

Ou

process(MyClass.ANOTHER_CONSTANT);

Mais aucune contrainte de compilation ne vous empêche de l'invoquer de cette façon:

process("a not defined constant value");

Vous n'auriez l'erreur qu'au moment de l'exécution et uniquement si vous effectuez à la fois une vérification de la valeur transmise.

Avec enum, les vérifications ne sont pas requises car le client ne peut transmettre qu'une valeur enum dans un paramètre enum.

Par exemple, voici deux valeurs définies dans une énumération classe (donc constante hors de la boîte):

public enum MyEnum {

    ONE_CONSTANT("value"), ANOTHER_CONSTANT(" another value");

    private String value;

    MyEnum(String value) {
       this.value = value;
    }
         ...
}

Voici une méthode qui s'attend à avoir une de ces valeurs enum comme paramètre:

public void process(MyEnum myEnum){
    ...    
}

Vous pouvez l'invoquer de cette façon:

process(MyEnum.ONE_CONSTANT);

Ou

process(MyEnum.ANOTHER_CONSTANT);

Mais la compilation ne vous permettra jamais de l'invoquer de cette façon:

process("a not defined constant value");

Où devrions-nous déclarer les constantes ?

Si votre application contient une seule classe existante qui possède une forte cohésion fonctionnelle avec les valeurs constantes, le 1) et le 2) apparaissent plus intuitifs.
Généralement, il facilite l'utilisation des constantes si elles sont déclarées dans la classe principale qui les manipule ou qui a un nom très naturel de deviner que nous allons trouver à l'intérieur.

Par exemple dans la bibliothèque JDK, les valeurs exponentielles et constantes pi sont déclarées dans une classe qui ne déclare pas seulement les déclarations constantes (java.lang.Math).

   public final class Math {
          ...
       public static final double E = 2.7182818284590452354;
       public static final double PI = 3.14159265358979323846;
         ...
   }

Les clients utilisant des fonctions mathématiques s'appuient souvent sur Math classe. Ainsi, ils peuvent trouver des constantes assez facilement et peuvent aussi se rappeler où E et PI sont définis de manière très naturelle.

Si votre application ne contient pas de classe existante qui a une cohésion fonctionnelle très spécifique et forte avec les valeurs constantes, les variantes 1) et 2) semblent plus intuitives.
Généralement, cela ne facilite pas l'utilisation des constantes si celles-ci sont déclarées dans une classe qui les manipule alors que nous avons aussi 3 ou 4 d'autres classes qui les manipulent autant que et aucune de ces classes ne semble être plus naturelle que d'autres pour héberger des valeurs constantes.
Ici, définir une classe personnalisée pour ne contenir que des valeurs constantes est logique.
Par exemple, dans la bibliothèque JDK, l'énumération java.util.concurrent.TimeUnit n'est pas déclarée dans une classe spécifique car il n'y a pas vraiment une et une seule classe spécifique JDK qui apparaît comme la plus intuitive pour la contenir:

public enum TimeUnit {
    NANOSECONDS {
      .....
    },
    MICROSECONDS {
      .....
    },
    MILLISECONDS {
      .....
    },
    SECONDS {
      .....
    },
      .....
}      

De nombreuses classes déclarées dans java.util.concurrent les utilisent : BlockingQueue, ArrayBlockingQueue<E>, CompletableFuture, ExecutorService , ... et vraiment personne d'entre eux ne semble plus approprié pour tenir l'énumération.

Une constante, de tout type, peut être déclarée en créant une propriété immuable dans une classe (c'est-à-dire une variable membre avec le modificateur final). Typiquement, les modificateurs static et public sont également fournis.

public class OfficePrinter {
    public static final String STATE = "Ready";  
}

Il existe de nombreuses applications où la valeur d'une constante indique une sélection à partir d'un n-tuple (par exemple enumeration) de choix. Dans notre exemple, nous pouvons choisir de définir un type énuméré qui limitera les valeurs assignées possibles (c'est-à-dire amélioré type de sécurité):

public class OfficePrinter {
    public enum PrinterState { Ready, PCLoadLetter, OutOfToner, Offline };
    public static final PrinterState STATE = PrinterState.Ready;
}

Une seule classe de constantes génériques est une mauvaise idée. Les constantes doivent être regroupées avec la classe à laquelle elles sont le plus logiquement liées.

Plutôt que d'utiliser des variables de toute nature (en particulier des énumérations), je suggère que vous utilisiez des méthodes. Créez une méthode avec le même nom que la variable et demandez-lui de renvoyer la valeur que vous avez affectée à la variable. Supprimez maintenant la variable et remplacez toutes les références par des appels à la méthode que vous venez de créer. Si vous sentez que la constante est assez générique que vous ne devriez pas avoir à créer une instance de la classe juste pour l'utiliser, puis faire de la méthode constante une méthode de classe.

FWIW, un délai d'attente en secondes devrait probablement être un paramètre de configuration (lu à partir d'un fichier de propriétés ou par injection comme dans Spring) et non une constante.

Quelle est la différence

1.

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

2.

public class MyGlobalConstants {
    private MyGlobalConstants () {} // Prevents instantiation
    public static final int TIMEOUT_IN_SECS = 25;
}

Et en utilisant MyGlobalConstants.TIMEOUT_IN_SECS partout où nous avons besoin de cette constante. Je pense que les deux sont les mêmes.

Je n'appellerais pas la classe la même (à part le boîtier) que la constante ... J'aurais au minimum une classe de "Paramètres", ou "Valeurs", ou "Constantes", où toutes les constantes vivraient. Si j'en ai un grand nombre, je les regrouperais dans des classes constantes logiques (UserSettings, AppSettings, etc.)

Pour aller plus loin, vous pouvez placer des constantes utilisées globalement dans une interface afin qu'elles puissent être utilisées à l'échelle du système. Par exemple

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

Mais ne l'implémentez pas ensuite. Référez-vous simplement à eux directement dans le code via le nom de classe complet.

Pour les constantes, Enum est un meilleur choix À mon HUMBLE avis. Voici un exemple

Classe publique myClass {

public enum myEnum {
    Option1("String1", 2), 
    Option2("String2", 2) 
    ;
    String str;
            int i;

            myEnum(String str1, int i1) { this.str = str1 ; this.i1 = i }


}

L'une des façons dont je le fais est de créer une classe "globale" avec les valeurs constantes et de faire une importation statique dans les classes qui ont besoin d'accéder à la constante.

static final est-ce ma préférence, je n'utiliserais un enum que si l'élément était effectivement énumérable.

J'utilise static final pour déclarer les constantes et aller avec la notation de nommage ALL_CAPS. J'ai vu pas mal d'instances de la vie réelle où toutes les constantes sont regroupées dans une interface. Quelques messages ont à juste titre appelé cela une mauvaise pratique, principalement parce que ce n'est pas à cela qu'une interface sert. Une interface doit appliquer un contrat et ne doit pas être un endroit où placer des constantes sans rapport. Le rassembler dans une classe qui ne peut pas être instanciée (via un constructeur privé) aussi est bien si la sémantique constante n'appartient pas à une ou plusieurs classes spécifiques. Je mets toujours une constante dans la classe à laquelle elle est la plus liée, car cela a du sens et est également facilement maintenable.

Les énumérations sont un bon choix pour représenter une plage 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'approche static final.

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

@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 énumérations d'une manière simple, elle prend beaucoup moins d'espace car c'est simplement un marqueur de compilation. Ce n'est pas une classe, ni la propriété de conversion automatique de chaîne.

C'est MAUVAISE habitude et terriblement Pratique AGAÇANTE pour citer Joshua Bloch sans comprendre le fondamentalisme fondamental.

Je n'ai rien lu Joshua Bloch, donc non plus

• il est un programmeur terrible
• ou les gens jusqu'à présent que je trouve le citant (Josué est le nom d'un garçon que je présume) utilisent simplement son matériel comme des scripts religieux pour justifier leurs indulgences religieuses de logiciel.

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

• l'Amour l'Identité Fondamentale de tout votre cœur et de tout votre esprit
• Aime ton prochain comme toi-même

Et donc de même le fondamentalisme du génie logiciel peut être résumé par

• consacrez-vous aux fondamentaux de ground-zero avec toute votre puissance et votre esprit de programmation
• et consacrer envers l'excellence de vos collègues programmeurs comme vous le feriez pour vous-même.

Aussi, parmi les milieux fondamentalistes bibliques, un corollaire fort et raisonnable est établi

• Aimez-vous d'abord. Parce que si vous ne vous aimez pas beaucoup, alors le concept "aimez votre prochain comme vous-même" n'a pas beaucoup de poids, car "combien vous vous aimez" est la ligne de référence au-dessus de laquelle vous aimeriez les autres.

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

Les lois fondamentales de la programmation logicielle

• paresse est la vertu d'un bon programmeur
• vous devez rendre votre vie de programmation 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 paresseux et donc aussi efficace que possible pour vos voisins-programmeurs qui travaillent avec vous et ramassent vos entrailles de programmation.

Interface-pattern constantes est une mauvaise habitude ???

En vertu de quelles lois de programmation fondamentalement efficace et responsable cet édit religieux tombe-t-il ?

Il suffit de lire l'article wikipedia sur les constantes de modèle d'interface (https://en.wikipedia.org/wiki/Constant_interface), et les excuses stupides contre lesquelles il déclare interface-constantes de motif.

• Quoi-Pas d'E? Qui sur terre en tant que programmeur logiciel n'utiliserait pas unE? La plupart d'entre nous sont des programmeurs qui préfèrent ne pas avoir à prouver avoir macho aescetic survivalisticism thro éviter l'utilisation d'unE.

  • Aussi - attendre un deuxième partisans de la programmation micro-fonctionnelle comme un moyen de ne pas avoir besoin d'unE. Attendez de lire mon explication sur la normalisation du modèle de données.

• Pollue l'espace de noms avec des variables non utilisées dans la portée actuelle? Il pourrait être des partisans de cet avis

  • ne sont pas conscients de la normalisation du modèle de données et de la nécessité de cette normalisation

• L'utilisation d'interfaces pour appliquer des constantes est un abus d'interfaces. Les partisans de tels ont une mauvaise habitude de

  • ne pas voir que les "constantes" doivent être traitées comme des contrats. Et les interfaces sont utilisées pour appliquer ou projeter la conformité à un contrat.

• Il 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 que votre gagne-pain persistant? IOW, pourquoi vous consacrer à une telle habitude de programmation AMBIVALENTE et mauvaise ?

Quelles que soient les excuses, il n'y a PAS D'EXCUSE VALABLE quand il s'agit de génie logiciel FONDAMENTALEMENT EFFICACE pour délégitimer ou décourager généralement l'utilisation de constantes d'interface.

Peu importe quelles étaient les intentions et les états mentaux originaux des pères fondateurs qui ont élaboré la Constitution des États-Unis. Nous pourrions débattre des intentions initiales 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 de ce que le les intentions "originales" des fondateurs de la plate-forme Java et du langage de programmation avaient pour l'interface. Ce qui m'importe, ce sont les fonctionnalités efficaces fournies par la spécification Java, et j'ai l'intention d'exploiter ces fonctionnalités au maximum pour m'aider à respecter les lois fondamentales de la programmation logicielle responsable. Je me fiche de savoir si je suis perçu comme "violant l'intention des interfaces". Je me fiche de ce que Gosling ou quelqu'un Bloch dit sur la "bonne façon d'utiliser Java", à moins que ce qu'ils disent ne le fasse pas violer mon besoin de fondamentaux épanouissants efficaces.

Le fondamental est la normalisation du modèle de données

Peu importe comment votre modèle de données est hébergé ou transmis. Que vous utilisiez des interfaces ou enums ou whatevernots, relationnel ou non-SQL, si vous ne comprenez pas le besoin et le processus de normalisation de 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 avons 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 le processus bloque un champ ou un domaine 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 maintenant sévèrement contestées et sévèrement contestées. par exemple, sa déclaration sur 1NF a été critiquée comme 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 dépôt et transmission. OMI, les instructions EF Codd devraient être complètement abandonnées et un nouvel ensemble d'instructions plus mathématiquement plausibles devrait être conçu.

Un défaut flagrant de EF Codd et la cause de son désalignement pour une compréhension humaine efficace est sa conviction que des données multidimensionnelles et mutables humainement perceptibles peuvent être perçues efficacement à travers un ensemble de mappages bidimensionnels fragmentaires.

Les principes fondamentaux de la normalisation des données

Ce que EF Codd a échoué à Express.

Dans chaque modèle de données cohérent, il s'agit de l'ordre gradué séquentiel de 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, leur granularité étant à un niveau où chaque instance d'un composant peut être identifiée et récupérée de manière unique.
   • absence d'alias d'instance. c'est à dire, aucun moyen par lequel une identification produit plus d'une instance d'une composant.
2. Absence de diaphonie d'instance. Il n'existe pas de la nécessité d'utiliser une ou plusieurs autres instances d'un composant afin de contribuer à l'identification d'une instance d'un composant.
3. L'unité et l'identité des composants/dimensions de données.
   • Présence de dés aliasing de composant. Il doit exister une définition selon laquelle un composant/dimension peut être identifié de manière unique. Qui est la définition principale d'un composant;
   • où le primaire la définition n'entraînera pas l'exposition de sous-dimensions ou de composants membres qui ne font pas partie d'un composant prévu;
4. Moyens uniques de distribution de composants. Il doit exister une, et une seule, telle définition de dé-aliasing de composant 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 de composant. Il n'existe pas de nécessité d'utiliser un membre d'un autre composant de contribuer à l'identification définitive d'un composant.
   • Dans une telle relation parent-enfant, l'identification, la définition d'un parent ne doit pas dépendre d'une partie de l'ensemble des membres des composants d'un enfant. Une composante membre de l'identité d'un parent doit être l'identité complète de l'enfant sans avoir recours à la référence à tout ou partie des enfants d'un enfant.
7. Préempter les apparences bimodales ou multimodales d'un données du modèle.
   • Lorsqu'il existe deux définitions d'un composant, c'est un signe évident qu'il existe deux différentes données-modèles mixtes comme l'une. Cela signifie qu'il y a incohérence au niveau du modèle de données ou au niveau du champ.
   • Un domaine d'application doit utiliser un seul et unique 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 en composantes statistiques d'énormes données, vous ne le faites probablement pas voir, ou voir la nécessité de traiter, la mutation des composants.
   • Un modèle de données peut voir certaines de ses composantes muter cycliquement ou progressivement.
   • Le mode peut être membre-rotation ou transposition-rotation.
   • La mutation de rotation des membres pourrait être un échange distinct de composants enfants entre composants. Ou où des composants complètement nouveaux devraient être définis.
   • La mutation transpositionnelle se manifesterait comme un membre dimensionnel mutant en un attribut, vice inversement.
   • Chaque cycle de mutation doit être identifié comme un modal de données distinct.
9. Versionner chaque mutation. De telle sorte que vous pouvez retirer une version précédente du modèle de données, lorsque peut-être le besoin 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 seul et unique modèle de données cohérent ou il existe un moyen pour qu'un modèle/version de données puisse s'identifier.

Sommes-nous vous demandez toujours si nous pourrions utiliser des constantes d'interface? Vrai?

Il y a des problèmes de normalisation des données en jeu plus conséquents que cette question banale. SI vous ne résolvez pas ces problèmes, la confusion que vous pensez que les constantes d'interface provoquent n'est relativement rien. Zilch.

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

Ensuite, vous déterminez ce qui entre dans l'injection de valeur, la propriété espace réservé de configuration, interfaces, chaînes finales, etc.

Si vous devez utiliser l'excuse d'avoir besoin de localiser un composant plus facile à dicter par rapport aux constantes d'interface, cela signifie que vous avez la mauvaise habitude de ne pas pratiquer la normalisation du modèle de données.

Peut-être que vous souhaitez compiler le modèle de données dans une version vcs. Que vous pouvez extraire une version distinctement identifiable d'un modèle de données.

Les valeurs définies dans les interfaces sont complètement assurées d'être non mutables. Et partageable. Pourquoi charger un ensemble de chaînes finales dans votre classe à partir d'une autre classe alors que tout ce dont vous avez besoin est cet ensemble de constantes ??

Alors pourquoi ne pas publier un contrat de modèle de données? Je veux dire 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 référencer les é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 pot.

Cela présente une complexité vers un échange d'exécution motivé par osgi ? Osgi est un moyen extrêmement efficace pour permettre aux programmeurs de continuer dans leurs mauvaises habitudes. Il existe de meilleures alternatives que osgi.

Ou pourquoi pas cela? Il n'y a pas de fuite des constantes privées dans le contrat publié. Toutes les constantes privées doivent être regroupées dans une interface privée nommée "Constantes", car je ne veux pas avoir à rechercher des constantes et je suis trop paresseux pour taper à plusieurs reprises "chaîne finale privée".

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 à considérer est lorsque l'interface est implémentée.

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

Après tout, je vis dans le pays des libres, des sauvages et chez les braves. Soyez courageux, soyez libre, soyez sauvage - utilisation de 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 s'aligner sur la leur? Peut-être que je devrais, mais ce n'est pas une situation idéale.