Moyen idéal pour organiser les constantes Java

Nous avons un énorme projet basé sur un ancien jdk 1.4. Nous avons migré l’application Web vers JDK 1.6 mais le code contient encore de nombreuses pratiques inefficaces et une mauvaise conception.

Un des points les plus douloureux des énormes classes Java de plus de 2500 lignes de code dans un seul fichier Java. Tant de fichiers comme ceux-ci.

Dans une tentative de refactorisation des classes, j’avais commencé par supprimer les constantes et en les plaçant dans différents fichiers Constants.java. mais comme il y a tant de constantes dans l’application, le fichier de constantes risque de prendre des proportions démesurées.

J’apprécierais les réactions sur la stratégie adoptée par les développeurs pour maintenir le code propre et maintenable.

    Gardez vos constantes dans la classe à laquelle elles sont liées, ne vous sentez pas obligées de les extraire. Il peut nettoyer le code de la classe, mais mélanger des constantes sans rapport dans un fichier ne constitue pas une amélioration.

    Gardez les choses liées ensemble .

    Et vous pouvez aussi les convertir en Enums lorsque cela est possible / utile (mais cela peut nécessiter un certain refactoring).

    Mettre toutes les constantes dans un seul fichier est une idée terrible! En particulier l’anti-motif uber-Constant où toutes les constantes sont dans une Interface que chaque classe doit implement . 10 façons de dimanche terrible! C’était une mauvaise idée quand les gens ont commencé à le faire au début des années 1990, avant Java! C’est définitivement une mauvaise idée en 2012!

    Cela signifie que vous mélangez de nombreuses informations non liées et créez des dépendances inutiles chaque fois que vous importez ce fichier uber-Constants. Les éléments qui vont ensemble doivent être réunis dans un Enum ou au moins dans la Class qui les utilise comme arguments de ses méthodes afin que, lorsqu’elles sont modifiées, vous sachiez comment effectuer facilement une parsing d’impact.

    Color constantes Imagine Color DaysOfTheWeek constantes DaysOfTheWeek mélangées à d’autres constantes de domaine métier et il y aura des centaines, voire des milliers, d’éléments dans un seul fichier. Comment cela peut-il être considéré comme une bonne idée? Dans tous les cas non traités, un Enum qui est un membre public inner d’une Class est une meilleure solution.

    Cela signifie également que vous avez un seul espace de noms plat pour essayer de créer des noms qui ne soient pas en conflit, leur nom et leur utilisation ne sont donc pas évidents. Ce n’est jamais un exercice positif.

    Lors de la conception et de la refactorisation, vous devez toujours:

    Efforcez-vous d’obtenir une cohésion élevée , cela signifie de garder les choses liées aussi étroitement que possible.

    S’efforcer d’obtenir un couplage lâche, cela signifie que ne laissez pas des choses non liées s’infiltrer dans d’autres scopes non liées.

    S’efforcer d’obtenir du code maintenable auto-documenté, des dizaines ou des centaines de déclarations private static final Ssortingng/int , toutes mélangées ensemble, ne correspond pas à cette définition, selon la norme de tous!

    En 2012, les constantes de style C sont une mauvaise solution lorsque vous Enum maintenant Enum , vous devez vous concentrer sur la conversion du plus grand nombre possible de ces groupes de constantes en Enum . Enum est de type sécurisé et peut être associé à d’autres atsortingbuts, propriétés et comportements pour les rendre intelligent . C’est la voie à suivre.

    Mettre des constantes dans un fichier Constant.java n’a pas de sens à mon avis (cela éloigne simplement le problème). Mais parfois, j’ai l’habitude de les regrouper pour nettoyer les objects et utiliser plusieurs fichiers pour les regrouper: DatabaseConstants.java , GraphicConstants.java et ainsi de suite … et bien sûr, utiliser des énumérations peut aussi être utile (et la meilleure pratique).

    edit: pour être précis, je travaille en fait avec l’application Java ME, c’est donc un moyen de “reproduire” les enums que je ne peux pas avoir, avec un “vocabulaire contrôlé” dans les classes abstraites (toutes les fonctionnalités de Java EE me manquent .. .)

    J’aimerais partager un modèle de conception pour les constantes que j’ai vu il y a quelques années et qui peut peut-être aider.

    Commencez par créer un fichier BaseConstant. Cela contiendra toutes vos constantes globales que tous les paquets pourraient utiliser.

    Maintenant, dans chaque sous-paquet de votre application, créez un fichier de constantes qui ne sera associé qu’au sous-paquetage. Donc si vous aviez. un sous-paquet appelé Login ne met que les constantes liées à la connexion. Mais la clé est d’étendre BaseConstants. Ainsi, vous voyez toutes les constantes globales dans le sélecteur IDE, mais lorsque vous ouvrez le fichier, vous ne voyez que les constantes de votre paquet. Cela dit, je pense que les fichiers constants peuvent être très lourds, dupliquer et difficiles à lire.

    Voici ce que je veux dire ..

     public class BaseConstants{ public static final Ssortingng GLOBAL1= "GLOBAL ssortingng"; public static final Ssortingng GLOBAL2= "another GLOBAL ssortingng"; } 

    Maintenant, dans tous vos autres paquets, créez un fichier comme ceci:

     class MyPackageConstants extends BaseConstants{ public static final Ssortingng LOCAL1 = "local Ssortingng" public static final Ssortingng LOCAL2= "ANOTHER LOCAL ssortingng"; } 

    dans votre IDE lorsque vous tapez “MyPackageConstants”. vous devriez voir toutes les constantes pour toute l’application.

    Pour quelqu’un qui visite cette page.

    Si vous ne souhaitez pas gérer plusieurs fichiers constants, voici le meilleur moyen de vous organiser.

     public interface Constants { public static final Ssortingng CREATE_USER = "createUser"; // Nested Interface. public interface ProjectConstants { public static final Ssortingng CREATE_PROJECT = "createProject"; public static final Ssortingng INVALID_SESSION = "Invalid Session"; // As you know they are implicity public static final. } }// Accessed as: Constants.ProjectConstants.CREATE_PROJECT 

    Mises à jour:

    Il est préférable d’utiliser Class. (Voir les commentaires. Merci keplerian.)

     public final class Constants { private Constants() { // ressortingct instantiation } public static final double PI = 3.14159; public static final double PLANCK_CONSTANT = 6.62606896e-34; } import static Constants.PLANCK_CONSTANT; import static Constants.PI; public class Calculations { public double getReducedPlanckConstant() { return PLANCK_CONSTANT / (2 * PI); } } 

    Je n’ai jamais entendu parler de mettre toutes les constantes dans un seul fichier java. Le meilleur moyen est de mettre les constantes associées aux classes en elles-mêmes, mais nommez-les avec une majuscule et des traits de soulignement comme celui-ci: EXAMPLE_CONSTANT

    Avez-vous essayé d’utiliser Enums pour toutes vos constantes? On m’a dit que c’était la méthode préférée depuis Java 1.5.

    http://docs.oracle.com/javase/1.5.0/docs/guide/language/enums.html

    Je pense que si vous avez plusieurs fichiers java de plus de 2 500 LOCs, la décision de placer les constantes devrait être le moindre de vos problèmes. Vous devriez avoir une idée claire de la structure du système restructuré. C’est probablement beaucoup plus difficile que de décider où coller les constantes et d’autres considérations syntaxiques, mais cela rest néanmoins à faire.