Quelle est la meilleure façon d'implémenter les constantes en Java? [fermé]
j'ai vu des exemples comme celui-ci:
public class MaxSeconds {
public static final int MAX_SECONDS = 25;
}
et supposait que je pouvais avoir une classe de constantes pour envelopper les constantes, les déclarer finales statiques. Je ne connais pratiquement aucun Java et je me demande si c'est la meilleure façon de créer des constantes.
28 réponses
c'est parfaitement acceptable, probablement même la norme.
(public/private) static final TYPE NAME = VALUE;
où TYPE est le type, NAME est le nom dans tous les casquettes avec des soulignements pour les espaces, et VALUE est la valeur constante;
je recommande fortement de ne pas mettre vos constantes dans leurs propres classes ou interfaces.
en tant que note secondaire: Les Variables qui sont déclarées finales et sont mutables peuvent encore être modifiées; toutefois, les variable ne peut jamais pointer vers un autre objet.
par exemple:
public static final Point ORIGIN = new Point(0,0);
public static void main(String[] args){
ORIGIN.x = 3;
}
Qui est légal et ORIGIN serait alors un point (3, 0).
je déconseille 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 augmente pour englober plus de 500 constantes qui ne sont pas du tout liées entre elles (étant liées à des aspects entièrement différents de la demande), cela se transforme généralement en un fichier de constantes complètement illisible. À la place:
- si vous avez accès à Java 5+, utilisez enums pour définir vos constantes spécifiques pour une zone d'application. Toutes les parties de la zone d'application doivent faire référence à des valeurs énums, et non à des valeurs constantes, pour ces constantes. Vous pouvez déclarer un enum similaire à la façon dont vous déclarez une classe. Les Enums sont peut-être la caractéristique la plus utile (et sans doute la seule) de Java 5+.
- si vous avez des constantes qui ne sont valables que pour une classe particulière ou l'une de ses sous-classes, déclarez-les comme étant soit protégées soit publiques et placez-les dans la classe supérieure hiérarchie. De cette façon, les sous-classes peuvent accéder à ces valeurs constantes (et si d'autres classes y ont accès via public, les constantes ne sont pas seulement valables 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 les valeurs retournées ou les valeurs d'argument doivent être particulières, il est parfaitement acceptable de définir des constantes sur cette interface pour que d'autres réalisateurs y aient accès. Cependant, évitez de créer une interface pour tenir constantes: il peut devenir aussi mauvais que d'une classe créée pour tenir des constantes.
C'est un "151920920 les" MAUVAISES PRATIQUES pour utiliser les interfaces pour tenir constantes (nommé constante de l'interface de modèle par Josh Bloch). Voici ce que Josh conseille:
si les constantes sont fortement liées à une classe ou une interface existante, vous doit les ajouter à la classe ou interface. Par exemple, tous les classes numériques primitives, comme entier et Double, export MIN_VALUE et MAX_VALUE constant. Si les constantes sont mieux vus que les membres d'un type énuméré, vous doit les exporter avec un enum type. Sinon, vous devez exporter le les constantes avec un noninstantiable 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;
}
à 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 essentiel que ces champs contiennent primitives de valeurs ou de références pour des objets immuables.
en Java efficace (2e édition), il est recommandé d'utiliser des enums au lieu des 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 devez-vous utiliser enums?
avec une réponse de:
chaque fois que vous avez besoin d'un ensemble fixe de constantes
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.
C'est plus" object oriently " que pour moi.
la création de constantes finales statiques dans une classe séparée peut vous mettre en difficulté. Le compilateur Java optimisera en fait ceci et placera la valeur réelle de la constante dans n'importe quelle classe qui la référencera.
si vous changez plus tard la classe 'Constants' et que vous ne faites pas de recompilation sur les autres classes qui font référence à cette classe, vous vous retrouverez avec une combinaison de valeurs anciennes et nouvelles utilisées.
au lieu de penser à ceux-ci comme les constantes, considérez-les comme des paramètres de configuration et créez une classe pour les gérer. Avoir des valeurs non-finales, et même envisager d'utiliser getters. Dans l'avenir, comme vous déterminer que certains de ces paramètres devrait être configurable par l'utilisateur ou de l'administrateur, il sera beaucoup plus facile à faire.
l'erreur numéro un que vous pouvez faire est de créer une classe globalement accessible appelée avec un nom générique, comme constantes. Cela est tout simplement jonché de déchets et vous perdez toute capacité à comprendre quelle partie de votre système utilise ces constantes.
au lieu de cela, les constantes doivent aller dans la classe qui les "possède". Vous avez une constante appelée TIMEOUT? Il devrait probablement aller dans votre classe Communications() ou Connection (). MAX_BAD_LOGINS_PER_HOUR? Va dans Utilisateur.)( Et ainsi de suite et ainsi de suite.
L'autre utilisation possible est Java .les fichiers de propriétés où les "constantes" peuvent être définies à l'exécution, mais pas facilement modifiables par l'utilisateur. Vous pouvez le paquet de ces dans votre .les bocaux et les référencer avec la classe resourceLoader.
C'est la bonne façon de faire.
les constantes sont généralement et non maintenues dans des classes distinctes de" constantes " parce qu'elles ne sont pas décelables. Si la constante est pertinente pour la classe courante, les garder là aide le développeur suivant.
je préfère utiliser des getters plutôt que des constantes. Ces getter peuvent retourner 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 comment le getter renvoie la constante.
l'autre avantage est que pour modifier la constante vous n'avez pas à tout recompiler qui l'utilise. Quand vous faites référence à un champ final statique, la valeur de cette constante est compilée dans n'importe quel bytecode qui la fait 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 article (#18) dans de Bloch "Java efficace .
un argument Bloch fait contre le modèle d'interface constante est que l'utilisation des 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 une bonne façon de déclarer un constant. Personnellement, je pense qu'il est préférable d'éviter de faire une classe séparée pour abriter toutes vos constantes, mais je n'ai jamais vu une 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 comme une énumération, considérez la structure enum disponible en 1.5 ou plus tard.
si vous utilisez une version antérieure à 1.5, Vous pouvez toujours effectuer des énumérations typesafe en utilisant Java normal classe. (Voir sur ce site pour plus d'informations).
basé sur les commentaires ci-dessus je pense que c'est une bonne approche pour changer la classe de constante globale démodée (ayant des variables finales statiques publiques) à son équivalent enum 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 renvoyer comme:
Constants.StringConstant.DB_HOST
une bonne conception orientée objet ne devrait pas nécessiter beaucoup de 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 à cette question. Pour commencer, les constantes en java sont généralement déclarées publiques, statiques et finales. Ci-dessous 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 qu'on s'attend généralement à ce que les interfaces soient implémentées. Ne serait-ce pas drôle:
String myConstant = IMyInterface.CONSTANTX;
au lieu de cela, je choisirais entre quelques différentes façons, basé sur une petite les compromis, et donc cela dépend de ce que vous avez 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 les constantes en Java?
une approche que nous devrions vraiment éviter : utiliser des interfaces pour définir des constantes.
la création d'une interface spécifiquement pour déclarer les constantes est vraiment la pire chose : elle va à l'encontre de la raison pour laquelle les interfaces ont été conçues : définir le contrat méthode(s).
même si une interface existe déjà pour répondre à un besoin spécifique, déclarer les constantes n'a vraiment pas de sens car les constantes ne devraient pas faire partie de l'API et du contrat fourni aux classes de clients.
pour simplifier, nous avons en gros 4 approches valables .
avec static final String/Integer zone:
- 1) en utilisant une classe qui déclare les constantes à l'intérieur, mais pas seulement.
- 1 variante) créant une classe dédiée à déclarer seulement les constantes.
avec Java 5 enum :
- 2) déclarant l'enum dans une classe d'utilisation connexe (so as a nested class).
- 2 variante) créant l'enum comme une classe autonome (ainsi définie dans son propre fichier de classe).
TLDR: Quelle est la meilleure façon et où trouver les constantes ?
dans la plupart des cas, la voie enum est probablement plus fine que la voie static final String/Integer 1519400920 "et personnellement je pense que la voie static final String/Integer devrait être utilisée seulement si nous avons de bonnes raisons de ne pas utiliser les énums.
Et sur 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 forte cohésion fonctionnelle avec des valeurs constantes. Si nous trouvons une telle classe, nous devrions l'utiliser comme constantes titulaire . Sinon, la constante doit être associé à aucune classe particulière.
static final String / static final Integer par rapport à enum
Enums utilisation est vraiment un moyen de fortement considérer.
Enums ont un grand avantage sur String ou Integer champ constant.
Ils imposent une contrainte de compilation plus forte.
Si vous définissez une méthode qui prend l'enum comme paramètre, vous ne pouvez passer qu'une valeur enum définie dans la classe enum(ou null).
Avec String et Integer vous pouvez les substituer avec n'importe quelles valeurs de type compatible et la compilation sera fine même si la valeur n'est pas constante définie dans les champs static final String / static final Integer .
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 une 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 n'empêche vous de l'invoquer de cette façon:
process("a not defined constant value");
vous auriez l'erreur seulement à l'exécution et seulement si vous faites à la fois un contrôle sur la valeur transmise.
avec enum, les vérifications ne sont pas nécessaires car le client ne peut passer qu'une valeur enum dans un paramètre enum.
par exemple, ici deux valeurs définies dans une classe d'enum (donc constant 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 un 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ù doit-on déclarer les constantes ?
si votre application contient une seule classe existante qui possède une cohésion fonctionnelle spécifique et forte avec les valeurs constantes, le 1) et le 2) semblent 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 les constantes pi sont déclarés dans une classe qui ne déclare pas seulement des 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 comptent souvent sur la classe Math .
Ainsi, ils peuvent trouver des constantes assez facilement et peuvent également se rappeler où E et PI sont définis d'une manière très naturelle.
Si votre application ne contient pas une classe existante qui a une très précises la cohésion fonctionnelle avec les valeurs constantes, la variante 1) et la variante 2) apparaît plus intuitive.
En général, il n'est pas facile d'utiliser les constantes si celles-ci sont déclarées dans une classe qui les manipule alors que nous avons aussi 3 ou 4 autres classes qui les manipulent autant 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 retenir que des valeurs constantes rend sens.
Par exemple, dans la bibliothèque JDK ,l'enum java.util.concurrent.TimeUnit n'est pas déclaré 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 {
.....
},
.....
}
plusieurs classes déclarées dans java.util.concurrent les utiliser :
BlockingQueue , ArrayBlockingQueue<E> , CompletableFuture , ExecutorService , ... et aucun d'entre eux ne semble plus approprié pour tenir l'enum.
une constante, de n'importe quel type, peut être déclarée en créant une propriété immuable qu'à l'intérieur d'une classe (qui est une variable membre avec le modificateur final ). En général, 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 d'un n-tuple (par exemple enumeration ) de choix. Dans notre exemple, nous pouvons choisir de définir une énumération Type qui limitera les valeurs attribuées possibles (c'est-à-dire amélioration du type-safety ):
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 logiquement reliées.
plutôt que d'utiliser des variables de n'importe quelle sorte (en particulier enums), je suggérerais que vous utilisez des méthodes. Créez une méthode avec le même nom que la variable et faites-lui retourner la valeur que vous avez assignée à la variable. Maintenant, supprimez la variable et remplacez toutes les références à celle-ci par des appels à la méthode que vous venez de créer. Si vous vous sentez que la constante est assez générique pour que vous n'ayez pas à créer une instance de la classe juste pour l'utiliser, puis faire de la méthode constante une méthode de classe.
FWIW, une valeur de délai en secondes devrait probablement être un paramètre de configuration (lu à partir d'un fichier de propriétés ou par injection comme au printemps) 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 utilisant
MyGlobalConstants.TIMEOUT_IN_SECS là 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 moins une classe de "Paramètres", ou de "Valeurs", ou des "Constantes", où toutes les constantes allait vivre. Si j'en ai un grand nombre, je les regrouperais dans des classes logiques constantes (UserSettings, AppSettings, etc.)
Pour aller plus loin, vous pouvez placer internationale des constantes dans une interface afin qu'ils puissent être utilisés par le système. Par exemple:
public interface MyGlobalConstants {
public static final int TIMEOUT_IN_SECS = 25;
}
mais ne l'appliquez pas. Juste faire référence directement dans le code par le nom de classe entièrement qualifié.
pour les constantes, Enum est un meilleur choix IMHO. 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 }
}
une des façons de le faire 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 ma préférence, je n'utiliserais un enum si l'article était effectivement énumérable.
j'utilise static final pour déclarer les constantes et suivre la notation ALL_CAPS. J'ai vu pas mal de cas réels où toutes les constantes sont regroupées dans une interface. Quelques billets ont à juste titre appelé cela une mauvaise pratique, principalement parce que ce n'est pas à cela que sert une interface. Une interface devrait exécuter un contrat et ne devrait pas être un endroit pour mettre des constantes sans rapport. La regrouper dans une classe qui ne peut pas être instanciée (à travers un constructeur privé) aussi est bien si la sémantique constante n'appartient pas à une classe spécifique(es). J'ai toujours mis une constante dans la classe à laquelle elle est la plus liée, parce que cela a du sens et est aussi facilement maintenable.
Enums sont un bon choix pour représenter une gamme de valeurs, mais si vous stockez des constantes autonomes avec un 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 énums lorsqu'il s'agit d'un ensemble de constantes. Cependant, si vous programmez sur Android il y a 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 à enums d'une manière simple, elle prend beaucoup moins d'espace car elle est simplement un marqueur de temps de compilation. Ce n'est pas une classe, et elle n'a pas non plus la propriété de conversion automatique de chaîne de caractères.
c'est mauvaise habitude et terriblement Pratique ennuyeuse pour citer Joshua Bloch sans comprendre le fondamentalisme fondamental de base zéro.
Je n'ai rien lu Joshua Bloch, donc non plus
- c'est un terrible programmeur
- ou le peuple jusqu'à présent que je trouve le citant (Josué est le nom d'un garçon, je présume) utilisent simplement son matériel comme des écritures religieuses pour justifier leur logiciel des indulgences religieuses.
comme dans le fondamentalisme de la Bible toutes les lois bibliques peuvent être résumées par
- aimez L'identité fondamentale avec tout votre cœur et tout votre esprit
- aimez votre prochain comme vous-même
et donc, de la même manière, le fondamentalisme de l'ingénierie logicielle peut être résumé par
- consacrez-vous à la rez-de-zéro fondamentaux de tout votre la programmation de la puissance et de l'esprit
- et de consacrer envers 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é
- le Premier amour de vous-même. 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, puisque "combien vous l'aimez vous-même" est la ligne de référence ci-dessus qui vous ferait aimer les autres.
de même, si vous ne vous respectez pas en tant que programmeur et si vous n'acceptez pas les déclarations et les prophéties de certains gourou de la programmation-nath sans remettre en question les fondamentaux, vos citations et votre confiance en Joshua Bloch (et autres) sont dénuées de sens. Et donc, vous n'auriez aucun respect pour vos collègues programmeurs.
le fondamental les lois de programmation du logiciel
- la paresse est la vertu d'un bon programmeur
- vous êtes à même de faire de votre programmation, la vie facile, comme paresseux, et donc aussi efficace que possible
- vous devez rendre les conséquences et les entrailles de votre programmation aussi facile, aussi paresseux et donc aussi efficace que possible pour vos neigbour-programmeurs qui travaillent avec vous et ramasser vos entrailles de programmation.
Interface-modèle à constantes est une mauvaise habitude ???
sous quelles lois de programmation fondamentalement efficace et responsable cet édit religieux tombe-t-il ?
vient de lire l'article de wikipedia sur interface-pattern constants ( https://en.wikipedia.org/wiki/Constant_interface ), et les excuses idiotes qu'il énonce contre les constantes d'interface-modèle.
-
Whatif-No IDE? Qui diable, 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 avoir macho aescetic survivalisticism thro éviter l'utilisation d'un IDE.
- Aussi - attendez une seconde promoteurs de micro-programmation fonctionnelle comme un moyen de ne pas avoir besoin d'un IDE. Attends de lire mon explication sur la normalisation des modèles de données.
-
Pollue l'espace de noms avec des variables non utilisées dans la portée actuelle? Il pourrait s'agir de partisans de cet avis
- ne sont pas au courant, et la nécessité pour, données modèle de normalisation
-
L'utilisation d'interfaces pour renforcer les constantes est un abus d'interfaces. Les partisans de tels ont une mauvaise habitude de
- ne voyant pas que les "constantes" doivent être traitées comme des contrats. Et les interfaces sont utilisées pour faire respecter ou projeter la conformité à un contrat.
-
il est difficile, voire impossible, de convertir les interfaces en classes mises en œuvre à l'avenir. Hah .... hmmm ... ???
- pourquoi voudriez-vous vous engager dans un tel modèle de programmation que votre subsistance persistante? IOW, pourquoi vous consacrer à une telle ambivalente et mauvaise habitude de programmation ?
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 généralement décourager l'utilisation de constantes d'interface.
peu importe ce qu'étaient à l'origine les intentions et les états mentaux des pères fondateurs qui ont élaboré la Constitution des États-Unis. Nous pourrions débattre des intentions originelles des pères fondateurs, mais tout ce que je me soucie est les déclarations écrites des États-Unis Constitution. 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 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 que la spécification Java fournit, et j'ai l'intention d'exploiter ces fonctionnalités au maximum pour m'aider à remplir les les lois de la responsable de la programmation logicielle. Je m'en fous si je suis perçue comme une "violation de l'intention pour les interfaces". Je ne me soucie pas de ce que Gosling ou Quelqu'un Bloch dit au sujet de la "bonne façon d'utiliser Java", à moins que ce qu'ils disent ne viole pas mon besoin de remplir efficacement les principes fondamentaux.
Le principe Fondamental est de Données-le Modèle de Normalisation
peu importe comment votre data-model est hébergé ou transmis. Que vous utilisiez des interfaces ou des enum ou whatevernots, relational ou no-SQL, si vous ne comprenez pas le besoin 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 quand nous avons un modèle de données cohérent, c'est seulement 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 domaine d'applications. Et c'est seulement alors que nous pouvons définir l'API de chaque processus fonctionnel.
même le les aspects de la normalisation des données tels que proposés par le Codd de L'EF sont maintenant sérieusement remis en question. par exemple, sa déclaration sur 1NF a été critiquée comme étant ambiguë, mal alignée et trop simplifiée, comme l'est le reste de ses déclarations, en particulier dans l'avènement des services modernes de données, de la technologie des rapports et de la transmission. L'OMI, l'EF Codd déclarations doivent être complètement abandonné et nouvelles, plus mathématiquement plausible consolidés être conçu.
Une flagrante de la faille de l'EF Codd et la cause de son mauvais alignement à la compréhension humaine efficace est sa croyance que humanly perceivable multi-dimensional, mutable-dimension données peuvent être efficacement perçus par un ensemble de morceaux 2 dimensions mappings.
les principes de La Normalisation des Données
ce que EF Codd n'a pas pu exprimer.
dans chaque modèle de données cohérent, il s'agit de l'ordre séquentiel graduel de cohérence des modèles de données à atteindre.
- L'unité et L'identité des instances de données.
- concevoir la granularité de chaque composante de données, leur granularité étant à un niveau où chaque instance d'une composante peut être identifiée et extraite de façon unique.
- en l'absence d'instance de l'aliasing. c'est à dire, aucun moyen par lequel une identification produit plus d'une instance d'un composant.
- absence d'instance la diaphonie. 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.
- l'unité et l'identité des composantes/dimensions des données.
- présence d'un désalignement du composant. Il doit exister une définition permettant d'identifier un élément ou une dimension de façon unique. Qui est la définition principale d'un composant;
- où la définition principale n'entraîne pas l'exposition de sous-dimensions ou d'éléments qui ne font pas partie d'un élément prévu;
- moyen Unique de vente de composants. Il doit exister une, et une seule, définition de désalignement de composant pour un composant.
- il existe une, et une seule, interface de définition ou contrat pour identifier un composant parent dans une relation hiérarchique de composants.
- Absence de composant de la diaphonie. 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. Un élément constitutif de l'identité d'un parent doit être l'identité complète de l'enfant sans qu'il soit nécessaire de faire référence à l'un quelconque ou à la totalité des enfants de l'enfant.
- Préempter bi-modale ou multi-modale apparences d'un data-model.
- s'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 terrain.
- un domaine d'application doit utiliser un seul modèle de données, de façon cohérente.
- détecter et identifier la mutation des composants. À moins que vous n'ayez effectué une analyse statistique des composantes de données énormes, vous ne voyez probablement pas, ou ne voyez pas la nécessité de traiter, la mutation des composantes.
- un modèle de données peut subir une mutation cyclique ou graduelle de certains de ses composants.
- le mode peut être la rotation des membres ou la transposition-rotation.
- mutation de rotation de membre pourrait être un échange distinct d'enfant composants entre composants. Ou où des composants entièrement nouveaux devraient être définis.
- mutation de transposition se manifesterait comme un membre dimensionnel Mutant en un attribut, vice versa.
- chaque cycle de mutation doit être identifié comme un modal de données distinct.
- Versionisez chaque mutation. Tel que vous pouvez sortir une version précédente du modèle de données, d'où peut-être le besoin de traiter une mutation de 8 ans du modèle de données.
dans un champ ou une grille de composantes inter-entretien-applications, il doit y avoir un seul et unique modèle de données cohérent ou il existe un moyen pour un modèle de données/version de s'identifier.
nous demandons toujours si nous pouvons utiliser les constantes D'Interface? Vraiment ?
il y a des questions de normalisation des données plus importantes que cette question banale. Si vous ne résolvez pas ces problèmes, la confusion que vous pensez que les constantes d'interface causent est comparativement rien. Zilch.
de la normalisation du modèle de données puis vous déterminez les composants comme variables, comme propriétés, comme constantes d'interface de contrat.
ensuite, vous déterminez qui va dans l'injection de la valeur, la propriété configuration placeholding, interfaces, chaînes finales, etc.
si vous devez utiliser l'excuse de devoir localiser un composant plus facile à dicter contre les constantes d'interface, cela signifie que vous êtes dans la mauvaise habitude de ne pas pratiquer la normalisation de modèle de données.
peut-être voulez-vous 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 valeursdéfinies dans les interfaces sont totalement 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 des constantes ??
alors pourquoi ne pas publier un contrat de modèle de données? Je veux dire, si vous pouvez gérer et de normaliser de façon 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 labels contractés de mes applis 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 me fiche de la structure du bocal.
cela présente de la complexité pour le temps d'exécution motivé par osgi échangeant ? Osgi est un moyen extrêmement efficace pour permettre aux programmeurs de conserver leurs mauvaises habitudes. Il y a de meilleures alternatives que l'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 doivent être groupées dans une interface privée appelée "constantes", parce que 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 à considérer est quand l'interface est implémentée.
ce n'est pas "l'intention originale" des interfaces? Comme je me soucierais de "l'intention originale" 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 des braves. Être courageux, être libre, être sauvage - utilisation de l'interface. Si mes collègues programmeurs refusent d'utiliser des moyens efficaces et paresseux de programmation, suis-je obligé par la règle d'or de diminuer mon efficacité de programmation pour m'aligner sur les leurs? Peut-être devrais-je le faire, mais ce n'est pas une situation idéale.