Java meilleures pratiques - Est de déclarer le constructeur avant les variables de classe une mauvaise chose?

Je suis d'entreprendre une "statique" code de procédure pas à pas du code Java à partir d'un collègue (un autre étudiant)

Pour moi, ce n'est pas logique; la lecture de bas en haut, ces "composant" les objets sont instanciés (et plus tard utilisé dans le constructeur) avant qu'ils ne soient déclarés. Mais, le code heureusement compile et s'exécute. Est-ce une mauvaise pratique?

Public Class theObject {

    private static final long aVariable = 123123123123123;

    public theObject(...){

        componentOne = new Component(...);
        componentTwo = new Component(...);

        ...
        ...
        componentOne.doSomething(...);
    }

    private Component componentOne;
    private Component componentTwo;
}
C'est de la POO!!!! ( coup .. tombent dans les puits). Autant que je sache, Il y a certain style-cop vérifications qui pourraient mettre en évidence le fait que les députés d'être déclarée avant le constructeur suivie par les déclarations de membres du public, mais cette déclaration n'avez pas toutes les implications sur la conpiler contrairement à des langages tels que C

OriginalL'auteur mitch_au | 2012-04-22

  1. 34

    De Sun Microsystems (maintenant pris en charge par Oracle) a publié son En Java Guide De Style en 1998, dans lequel ils ont recommandé une organisation en particulier aux déclarations de classe:

    1. Variable statique champ déclarations
    2. Variable d'Instance champ déclarations
    3. Initialiseur statique
    4. Membre statique intérieure déclarations de classe [*]
    5. Statique des déclarations de méthode de
    6. Instance d'initialiseur
    7. Instance constructeur déclarations
    8. Membre de l'Instance intérieure déclarations de classe [*]
    9. Exemple des déclarations de méthode de

    Remarque que cela met les données des déclarations au début du fichier. (Un plus tôt Soleil publication de 1997 n'a pas tout couvrir dans la liste ci-dessus.) L'importance de la commande est dans le champs statiques et dans les champs d'instance, et seulement si les champs contiennent des initialiseurs qui font référence à d'autres domaines. Vous ne pouvez pas utiliser un champ dans un initialiseur avant qu'elle-même a été initialisé. De même, un initialiseur (articles 3 et 6) ne peut pas faire une référence directe à un champ, à l'exception que la cible d'un acte de cession. (Voir la Java Langage De Spécification, La Section 8.3.3, pour plus d'informations sur de telles références.) Autant que je sache, rien d'autre à propos de l'importance de l'ordre.

    [*] La terminologie dans la liste ci-dessus (qui est mot pour mot le guide de 1998) est mis à jour en ce qui concerne les articles 4 et 8. Plus précisément, à partir de la Java tutoriel sur les classes imbriquées:

    Terminologie: classes Imbriquées sont divisés en deux catégories: statique et non statique. Classes imbriquées qui sont déclarées static sont appelés statique classes imbriquées. Non statique classes imbriquées sont appelés les classes internes.

    Dans l'usage moderne, il n'y a pas une telle chose comme un "membre statique intérieur de la classe".

    OriginalL'auteur Ted Hopp

  2. 9

    Il n'y a pas de réel consensus à ce sujet. La plupart des gens déclarer des variables de classe dans le haut de l'implémentation de la classe, suivie par les méthodes mais ce n'est pas une exigence. Certains livres comme le Code Complet suggèrent de déclarer des variables aussi près que possible de leur première utilisation. Cela aide à réduire la portée d'une variable à un minimum.

    +1 Code Complet est à lire absolument pour tous les graves programmeur
    si la variable n'est pas "perdu" dans le code. Si vous déclarez chaque variable en haut de chaque fichier, vous pourriez ne pas savoir à quoi sert-il lorsque vous examinez le code ou simplement de travailler sur elle. Le principe est: "je ne vais pas utiliser cette variable avant de me déclarer cette fonction alors, pourquoi voudrais-je la déclarer avant aujourd'hui?". Je n'ai personnellement pas vraiment de suivre cette règle, mais je sais que certaines personnes le font et il est recommandé dans le Code Complet.

    OriginalL'auteur Chris911

  3. 6

    La déclaration générale de l'ordre dans java, (Référence: En Java Guide De Style)

         public class DeclarationOrder {

        //Class (static) variables
        public static int publicClassVariable;
        protected static int protectedClassVariable;
        static int defaultClassVariable;
        private static int privateClassVariable;

        //Instance variables
        public int publicInstanceVariable;
        protected int protectedInstanceVariable;
        int defaultInstanceVariable;
        private int privateInstanceVariable;

        //Constructors
        public DeclarationOrder() {
            //Public Constructor
        }
        protected DeclarationOrder(int var) {
            //Protected Constructor
        }
        DeclarationOrder(String var) {
            //Default Constructor
        }
        private DeclarationOrder(Double var) {
            //private Constructor
        }

        //Class (static) Methods
        public static void publicClassMethod(){}
        protected static void protectedStaticMethod(){}
        static void defaultStaticMethod() {}
        private static void privateStaticMethod(){}

        //Instance Methods
        public void publicInstaceMethod() {}
        protected void protectedInstanceMethod() {}
        void defaultInstanceMethod() {}
        private void privateInstanceMethod() {}
    }

    L'ordre au sein de chaque ensemble doit être,

    1. Public
    2. Protégé
    3. Niveau du colis (pas de modificateur d'accès)
    4. Privé

    OriginalL'auteur Vidura Mudalige

  4. 5

    Non, ils ne sont pas instancié avant qu'ils ne soient déclarés. L'ordre d'initialisation est fixé en Java et il n'a pas d'importance où dans le code que vous mettez vos déclarations et les constructeurs.

    Comme pour la convention, il dépend vraiment de ce que vous êtes à l'aise avec. Alors que la vérité est la convention est de déclarer les champs en premier, puis les constructeurs, votre approche est aussi valable qu'une autre, tant qu'il n'est pas contre votre nature ou les règlements de l'entreprise.

    En outre, il est beaucoup plus dangereux trucs à mettre dans votre code qui le rend moins lisible, comme une lettre de variables ou de l'utilisation intensive de moins de structures communes (opérateur ternaire pour des conditions complexes, par exemple). L'organisation du code est l'un des moins préoccupations, comme toute bonne IDE peut réorganiser le code par ce que les paramètres de vous y mettre.

    OriginalL'auteur Jakub Zaverka

  5. 2

    La ordre dans laquelle les membres d'une classe (méthodes, attributs) sont déclarées n'est pas pertinent. Par convention, il est fréquent d'abord déclarer tous les attributs et les constantes, les méthodes.

    Par exemple, dans votre code: il est possible d'initialiser les attributs dans le constructeur et puis déclarer les attributs, tout simplement parce que lorsqu'une classe est compilé toutes les déclarations d'attributs seront pris en compte, et plus tard, lorsque le constructeur est en fait appelé, les attributs seront trouvés. Notez que les attributs du constructeur ne sont pas accessibles au moment de la compilation, c'est pourquoi ils ne produisent pas une erreur; ils ne sont accessibles au moment de l'exécution.

    La commande class X { int a = b + 1 ; int b = 100 } n'est pas le même que class Y { int b = 100 ; int a = b + 1 ; } class X ne devrait pas compiler, mais il n'y a rien de mal avec class Y
    Comme indiqué dans ma réponse, le déclaration ordre des attributs n'a pas d'importance. Dans votre exemple vous êtes initialisation attributs, bien sûr, c'est une histoire complètement différente.

    OriginalL'auteur Óscar López

  6. 2

    Il est contraire aux conventions normales, et (ainsi) il rend le code moins lisible pour les personnes qui attendent les conventions normales à suivre ... c'est à dire la plupart des programmeurs Java.

    D'autre part, si le code n'systématiquement, à la suite d'un accord local de la convention de codage, puis les lecteurs pourront s'habituer à elle.

    Donc la réponse à la question "Est-ce une mauvaise pratique?" est que cela dépend de votre accord convention de codage, et ce qu'il dit à ce sujet.

    Mais le méta-réponse est que de faire une revue de code sans un accord de convention de codage est une très mauvaise idée. Si il n'existe pas de convention de codage, il n'y a pas de base objective pour l'examen de code de style. Vous êtes responsable de se retrouver avec un mauvais résultat.

    OriginalL'auteur Stephen C

  7. 2

    Principales de Java Language specification définir dans les sections 8.1.1, 8.3.1 et 8.4.3 flux suivant que nous avons à l'aide de:

    1. public
    2. protégé
    3. privé
    4. résumé
    5. statique
    6. final
    7. transitoire
    8. volatils
    9. synchronisé
    10. natif
    11. strictfp

    Cet ordre que nous avons à utiliser lorsque l'on écrit le code en Java 😉

    Lien vers la Spécification du Langage Java

    OriginalL'auteur Dmytro Melnychuk