Meilleure pratique : classement de public/protégé/privé dans la définition de la classe ?

Question

Je commence un nouveau projet à partir de zéro et je veux qu'il soit propre / qu'il ait de bonnes normes de codage. Dans quel ordre les développeurs chevronnés d'ici aiment-ils présenter les choses à l'intérieur d'une classe ?

A : 1) méthodes publiques 2) méthodes privées 3) vars publics 4) vars privés

B : 1) vars publics 2) vars privés 3) méthodes publiques 4) méthodes privées

C : 1) vars publiques 2) méthodes publiques 3) méthodes privées 4) vars privées

J'aime généralement placer les variables statiques publiques en haut de la liste, mais alors une méthode statique publique serait-elle listée avant votre constructeur, ou le constructeur devrait-il toujours être listé en premier ? Ce genre de choses...

Je sais que c'est délicat, mais je me demandais quelles étaient les meilleures pratiques en la matière.

PS : non, je n'utilise pas Cc#. Je sais. Je suis un luddite.

Answer 1

En Code propre Robert C. Martin conseille aux codeurs de toujours placer les variables membres en tête de classe (les constantes d'abord, puis les membres privés) et les méthodes devraient être ordonnées de manière à ce qu'elles se lisent comme une histoire qui n'oblige pas le lecteur à sauter trop souvent dans le code. Il s'agit là d'une manière plus sensée d'organiser le code que par modificateur d'accès.

Answer 2

La meilleure pratique consiste à être cohérent .

Personnellement, je préfère mettre public d'abord, puis les méthodes protected les méthodes, suivies par les méthodes private des méthodes. Les membres données devrait en général toujours être privée ou protégée, sauf si vous avez une bonne raison de ne pas le faire.

La raison pour laquelle j'ai mis public au sommet est qu'elle définit la méthode interface pour votre classe, de sorte que toute personne consultant votre fichier d'en-tête devrait être en mesure de voir cette information immédiatement.

En général, private y protected sont moins importants pour la plupart des personnes qui consultent le fichier d'en-tête, à moins qu'elles n'envisagent de modifier les éléments internes de la classe. Le fait de les garder "hors du chemin" permet de s'assurer que ces informations ne sont maintenues que dans un fichier d'en-tête. base du besoin de savoir L'encapsulation est un des aspects les plus importants de l'encapsulation.

Answer 3

Personnellement, j'aime bien placer le public en tête, puis le protégé et enfin le privé. La raison en est que lorsque quelqu'un ouvre l'en-tête, il voit d'abord ce à quoi il peut accéder, puis plus de détails au fur et à mesure qu'il défile vers le bas.

Si l'on ne doit pas avoir à regarder les détails de l'implémentation d'une classe pour pouvoir l'utiliser, c'est que la conception de la classe n'est pas bonne.

Answer 4

Je pense que j'ai une philosophie différente de celle de la plupart des gens. Je préfère regrouper les éléments apparentés. Je ne supporte pas d'avoir à sauter d'un élément à l'autre pour travailler avec une classe. Le code doit être fluide et l'utilisation d'un ordre plutôt artificiel basé sur l'accessibilité (public, privé, protégé, etc.) ou instance versus statique ou membre versus propriété versus fonction n'aide pas à maintenir un flux agréable. Ainsi, si j'ai une méthode publique Method qui est mis en œuvre par des méthodes d'aide privées HelperMethodA , HelperMethodB etc., alors plutôt que d'avoir ces méthodes éloignées les unes des autres dans le fichier, je les garderai proches les unes des autres. De même, si j'ai une méthode d'instance qui est implémentée par une méthode statique, je les regrouperai également.

Mes cours ressemblent donc souvent à ceci :

class MyClass {
    public string Method(int a) {
        return HelperMethodA(a) + HelperMethodB(this.SomeStringMember);
    }

    string HelperMethodA(int a) { // returns some string }

    string HelperMethodB(string s) { // returns some string }

    public bool Equals(MyClass other) { return MyClass.Equals(this, other); }

    public static bool Equals(MyClass left, MyClass right) { // return some bool }

    public double SomeCalculation(double x, double y) {
        if(x < 0) throw new ArgumentOutOfRangeException("x");
        return DoSomeCalculation(x, y); 
    }

    const double aConstant;
    const double anotherConstant;
    double DoSomeCalculation(double x, double y) {
        return Math.Pow(aConstant, x) * Math.Sin(y) 
            + this.SomeDoubleMember * anotherConstant;
    }       
}

Answer 5

Voici ce que je commanderais

1. Variables statiques
2. Méthodes statiques
3. Variables publiques
4. Variables protégées
5. Variables privées
6. Constructeurs
7. Méthodes publiques
8. Méthodes protégées
9. Méthodes privées

J'utilise les règles suivantes :

• statique avant tout
• les variables avant les constructeurs avant les méthodes (je considère les constructeurs dans la catégorie des méthodes)
• public avant protégé avant privé

L'idée est de définir l'objet (les données) avant les comportements (les méthodes). Les statiques doivent être séparées parce qu'elles ne font pas vraiment partie de l'objet, ni de son comportement.