Dans quel ordre définir les getters et setters? [fermé]

14

Existe-t-il une meilleure pratique pour que l'ordre définisse les getters et les setters? Il semble y avoir deux pratiques:

  • paires getter / setter
  • premiers getters, puis setters (ou l'inverse)

Pour éclairer la différence, voici un exemple Java de paires getter / setter:

public class Foo {
    private int var1,
    var2,
    var3;

    public int getVar1() {
    return var1;
    }

    public void setVar1(int var1) {
    this.var1 = var1;
    }

    public int getVar2() {
    return var2;
    }

    public void setVar2(int var2) {
    this.var2 = var2;
    }

    public int getVar3() {
    return var3;
    }

    public void setVar3(int var3) {
    this.var3 = var3;
    }
}

Et voici un exemple Java de premiers getters, puis de setters:

public class Foo {
    private int var1,
    var2,
    var3;

    public int getVar1() {
    return var1;
    }

    public int getVar2() {
    return var2;
    }

    public int getVar3() {
    return var3;
    }

    public void setVar1(int var1) {
    this.var1 = var1;
    }

    public void setVar2(int var2) {
    this.var2 = var2;
    }

    public void setVar3(int var3) {
    this.var3 = var3;
    }
}

Je pense que ce dernier type de classement est plus clair à la fois dans le code et dans les diagrammes de classes, mais je ne sais pas si cela suffit pour exclure l'autre type de classement.

NN
la source

Réponses:

8

La première façon. S'il est possible, toujours regrouper ou rester proche des fonctions associées qui opèrent sur les mêmes membres.

Si vous organisez votre code de cette manière, cela rend la refactorisation plus claire et plus facile, car si une classe peut être factorisée d'une autre qui en fait trop, la pièce factorisable tourne généralement autour d'une variable membre spécifique.

En général, il est plus facile de déboguer, de comprendre et de manipuler du code lorsque vous pouvez voir tous sur la même page tout le cycle de vie d'un objet / variable. J'irais jusqu'à dire que la mise en page du code basée principalement sur des superficialités telles que la portée et l'ordre alphabétique signifie en fait que vous manquez des opportunités de refactorisation car vous ne pouvez pas les voir.

Benoît
la source
Souhaitez-vous inclure un argument supplémentaire pour expliquer pourquoi les fonctions fonctionnant sur les mêmes membres doivent être maintenues ensemble?
NN
Ajout de quelques raisons.
Benoît
25

Si vous faites partie d'une équipe, faites ce qu'ils font habituellement. Sinon, choisissez celui que vous aimez le plus. Sur l'échelle des choix de conception importants, c'est probablement quelque part près de "quel pouce dois-je utiliser pour frapper la barre d'espace?"

axblount
la source
7
Complètement d'accord. Cela tombe sous le titre de "ne pas transpirer les petites choses", qui devrait être la règle de codage standard n ° 0 de tout le monde ( c'est la règle n ° 0 dans "C ++ Coding Standards" par Herb Sutter et Andre Alexandrescu.)
David Hammen
Je suis sûr que les gens se sont beaucoup disputés sur le pouce à utiliser pour frapper la barre d'espace)))
superM
@Michael Je suis aussi un vrai droitier. J'ai essayé d'utiliser exclusivement ma gauche, mais c'était extrêmement difficile et ma frappe a ralenti.
axblount
@axblount Je suis droitier, mais utilisez toujours mon pouce gauche. Je viens d'essayer ma droite et j'ai eu la même expérience que vous avez décrite. Je tape également "y" avec ma main gauche pour une raison quelconque.
KChaloux
6

Cela peut aussi dépendre de la langue. En Java, il n'y a aucun avantage réel à l'un ou l'autre ordre, mais en C #, par exemple, vous avez le concept de "propriétés", qui regroupent le getter et le setter, donc il applique en quelque sorte cet ordre. Dans un langage comme C ++, où vous voudrez peut-être une visibilité différente sur les getters et les setters (par exemple, setter privé, getter public), vous feriez probablement le contraire, car le modificateur de visibilité est donné une fois pour plusieurs méthodes, plutôt qu'individuellement pour chaque .

Darrel Hoffman
la source
5

Pour autant que je sache, il n'y a pas de convention unique. La section Oracle Java Code Conventions sur l'organisation des fichiers ne mentionne pas explicitement le placement des getters et setters, mais elle dit:

Ces méthodes doivent être regroupées par fonctionnalité plutôt que par portée ou accessibilité.

Cela ne fournit aucune indication - je pourrais faire valoir que l'un ou l'autre placement répond à ces critères.

Quelque chose à considérer est que les IDE modernes vous permettent d'avoir des vues plus abstraites de la structure de vos fichiers qu'en tant que composant de code textuel. Ceci, couplé à de puissants outils de recherche, devrait faciliter la navigation dans les fichiers et trouver les méthodes appropriées même dans les fichiers volumineux.

Par exemple, Eclipse fournit une vue Structure qui vous permet de trier et de filtrer les méthodes et les champs de différentes manières, et de naviguer jusqu'à leur emplacement dans les fichiers. NetBeans avait des fonctionnalités similaires, et je soupçonne que la plupart des autres IDE font de même.

La seule fois où cela peut être important, c'est si vous lisez le code en dehors de votre IDE. Un exemple peut être d'utiliser un outil de révision de code externe ou d'afficher des deltas à partir de votre système de contrôle de version.

La meilleure solution serait simplement d'être cohérent entre les fichiers d'un projet. Trouvez une norme, documentez-la et respectez-la.

Thomas Owens
la source
1

Regroupez le getter et le setter pour un même champ, par paires.

En regroupant tous les getters et tous les setters ensemble, il est difficile de dire quels champs ont juste des getters ou juste des setters.

Lorsque je lis du code ou que je recherche des fonctionnalités spécifiques, j'envisage une classe comme ayant des champs, chaque champ ayant un getter et un setter. Cela n'a pas de sens pour moi qu'une classe ait un groupe de getters et un groupe de setters, chacun ayant des champs.

M. Dudley
la source
Donc, votre argument est que les getters pour un champ doivent être associés à des getters pour ce champ, car cela facilite la vue d'ensemble de la façon dont certains champs d'une classe sont traités?
NN
Cela, et le modèle conceptuel de ce qu'est une classe. Les cours doivent être organisés principalement par fonctionnalité. Lors de la création d'une classe, vous pouvez décider qu'elle a besoin d'un champ mutable visible par le public. C'est la "fonctionnalité" conceptuelle, pas l'expression syntaxique à travers les méthodes getter et setter.
M. Dudley
0

Ever Java IDE peut générer des getters et setters pour vous. Utilisez simplement cette fonctionnalité et laissez l'ordre de ces méthodes comme l'IDE l'a créé. C'est du code généré, ne le touchez pas inutilement.

user281377
la source
J'en suis conscient. Cependant, par exemple dans Eclipse, vous pouvez choisir entre différentes commandes .
NN
Droite. L'option par défaut "Champs dans les paires getter / setter" semble plus utile, car vous pouvez ajouter plus de champs et générer plus d'accesseurs plus tard sans avoir à vous soucier de la méthode qui va où, mettez simplement les deux à la fin.
user281377