En Java, les assistants privés devraient-ils aller au-dessus ou au-dessous des méthodes publiques? [fermé]

24

J'ai remarqué qu'un collègue et moi avons des pratiques opposées concernant l'ordre des méthodes dans nos classes Java. L'un de nous commence une classe avec ses principales méthodes publiques, puis met tous les assistants privés par la suite. L'autre d'entre nous s'assure que les méthodes publiques sont à la toute fin.

De toute évidence, ce n'est qu'une question de style et il n'y a pas de bonne réponse. Cependant, avant de décider que cette question n'est qu'un autre combat entre les Yooks et les Zooks et de choisir arbitrairement l'un ou l'autre, je me demandais s'il existait peut-être une recommandation de guide de style Java standard ou une raison pratique pour laquelle une approche est meilleure que l'autre.

java coding-style Brandon Yarbrough
la source
13
Ça n'a pas d'importance. Lancer une pièce. Choisissez-en un. Restez avec lui.
doublon possible du placement des méthodes d'assistance
Kilian Foth
@KilianFoth - Cette question a été posée 3 mois plus tôt et a plus de réponses. Cela ne ferait-il pas de la question en question un double de cette question?
Brandon Yarbrough

Réponses:

25

Bien que cela se résume normalement à vos préférences, vous devez certainement essayer d'adhérer à une norme commune au sein de votre organisation. Donc, quoi que vous décidiez, choisissez une norme et adoptez-la universellement.

Quant au choix, si vous suiviez les suggestions proposées dans Clean Code , vous seriez en mesure de lire le fichier de haut en bas comme un article de journal, ce qui suggérerait naturellement que les méthodes d'assistance apparaissent après les méthodes qu'elles sont. portion. Cela conduirait à une lisibilité maximale de la structure du code. Donc, si vous deviez avoir

public void doSomething()
{
     helpMe();
     helpMeAgain();
}

Votre dossier serait structuré comme 

public void doSomething() { }
private void helpMe() { }
private void helpMeAgain() { }

Un autre effet secondaire de cela est que vous découvrez que vos assistants ont leurs propres assistants, et cela vous aide à comprendre ce que vous avez vraiment est une autre classe vivant dans votre fichier, et vous pouvez refactoriser proprement pour l'extraire dans sa propre classe car ces méthodes sont déjà regroupés dans l'ordre. Mais c'est un avantage secondaire.

Anthony Pegram
la source
Heureux que vous ayez dit cela, sinon je l'aurais fait. J'ai demandé à Bob Martin lui-même comment il ordonne les choses si 2 méthodes utilisent chacune une 3e méthode. Dans ce cas, il place le 3e sous les deux autres.
Daniel Kaplan
1
Votre exemple ne le montre pas, mais cela conduit à des méthodes publiques mélangées parmi les méthodes privées. J'utilise cette technique, mais souvent, je me sens déchiré et je veux augmenter toutes les méthodes publiques au sommet, car il y a aussi beaucoup à dire pour lire facilement l'interface publique.
Sean
@Sean, eh bien, j'essayais généralement de limiter soit l'API publique de ma classe, soit de la laisser comme façade le cas échéant, mais de pousser les assistants d'implémentation vers les collaborateurs. Tester, refactoriser, extraire, répéter. Mais cela dépend bien sûr de jusqu'où vous voulez aller. Je préfère mes petites classes.
Anthony Pegram
11

Les méthodes publiques sont l'interface de la classe. Une personne intéressée à utiliser votre classe ne se souciera que de l'interface. Du point de vue d'un utilisateur de classe, il serait utile d'avoir d'abord les méthodes publiques pour réduire le défilement.

mike30
la source
5

En C et C ++, les méthodes d'assistance sont souvent placées en premier car vous n'avez alors pas besoin de déclaration. Beaucoup de gens ont repris cette habitude dans d'autres langues où cela n'a pas d'importance.

Je préfère les méthodes publiques par dessus parce que généralement lorsque j'ouvre un fichier, je recherche son interface publique. Je ne veux pas avoir à faire défiler tous les détails de la mise en œuvre. C'est aussi le style le plus populaire que j'ai vu, il y a donc cela à dire pour la convention.

Karl Bielefeldt
la source
2

J'aime que l'ordre des méthodes dans une classe soit basé sur la lisibilité et le contexte, pas sur la visibilité.

c'est-à-dire qu'une méthode «ouverte» appartient probablement avant une «fermeture». Si deux méthodes publiques 'a' et 'b' appellent un 'c' privé, et qu'elles sont les seules à l'appeler - alors j'aime que 'c' soit à côté d'elles.

Je ne pense pas qu'une convention d'ordonnancement des méthodes basée sur la visibilité soit une bonne chose.

ptyx
la source
1

J'ai tendance à préférer voir mes classes où les membres sont classés par ordre d'importance / visibilité (ici par importance, je veux dire qui ont un impact direct sur l'interface publique).

Ainsi, les fonctions privées ont tendance à être réduites.

Il y a des exceptions à cela où j'aurai également tendance à regrouper des fonctionnalités similaires, il est donc toujours possible de trouver de petites fonctions privées entremêlées avec les trucs publics.

C'est, comme vous l'avez dit, une question de goût.

Cependant, lorsque je travaille sur du code qui n'est pas le mien, j'essaierai de suivre les conventions utilisées dans le projet.

Une bonne façon que j'ai trouvée pour garder une trace de cela est de (en supposant ici que vous travaillez avec Eclipse) créer une configuration de formatage de code et l'exporter avec la source du projet et la valider en contrôle de source. De cette façon, la dernière et la plus grande convention de code du projet est à quelques clics de souris pour configurer et faire un habbit de CTRL-SHIFT-F avant que vous ne validiez, vous éviterez beaucoup d'arguments.

Le bonus supplémentaire de l'utilisation de formateurs automatiques est que vous pouvez faire des choses dans n'importe quelle convention qui vous rend heureux et formater simplement le code avant de le valider. YMMV selon ladite convention et l'outil de formatage.

Newtopian
la source