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

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.

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.

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?"

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 .

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.

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.

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.