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

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.

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.

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.

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.

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.

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.