Existe-t-il des conventions de classement des méthodes Java? [fermé]

159

J'ai une classe de grande taille (une quarantaine de méthodes) qui fait partie d'un package que je vais soumettre en tant que cours. Actuellement, les méthodes sont assez mélangées en termes d'utilité publique / privée, etc. et je veux les ordonner de manière raisonnable. Existe-t-il une manière standard de procéder? Par exemple, normalement les champs sont listés avant les méthodes, les constructeurs sont listés avant les autres méthodes, et les getters / setters en dernier; qu'en est-il des méthodes restantes?

java methods conventions

— Fredley
source

Notez également que lorsque vous travaillez avec du code comme celui-ci, la plupart des IDE vous permettent de voir automatiquement la définition de tout ce qui se trouve sous le curseur. Cela signifie que vous n'avez rien d'autre à faire que de regarder.

— Thorbjørn Ravn Andersen

Si vous avez 40 méthodes dans une seule classe - vous le faites mal

— Ben

132

Certaines conventions répertorient d'abord toutes les méthodes publiques, puis toutes les méthodes privées - cela signifie qu'il est facile de séparer l'API de l'implémentation, même lorsqu'il n'y a pas d'interface impliquée, si vous voyez ce que je veux dire.

Une autre idée consiste à regrouper les méthodes associées - cela facilite la détection des coutures où vous pouvez diviser votre grande classe existante en plusieurs plus petites et plus ciblées.

— Jon Skeet
source

1

+1. Je préfère trier par visibilité. Shame Eclipse ne peut pas le faire automatiquement (il regroupera toujours tous les constructeurs et toutes les méthodes ensemble.)

— finnw

16

@finnw, déposez un rapport de bogue. On sait que des choses plus étranges ont été mises en œuvre à partir de là.

— Thorbjørn Ravn Andersen

3

@Ben: Mon expérience est que tout «jamais» n'aura d'exceptions.

— Jon Skeet

1

@JonSkeet dans quelques cas, où les conventions de classement ne sont plus pertinentes, testez les classes par exemple. Il est préférable de ne pas écrire de mauvais code que de savoir comment organiser un mauvais code.

— Ben

1

@Ben: Je pense que nous devrons accepter de ne pas être d'accord. J'ai écrit du code où il y a très naturellement de nombreux membres, sans violer aucune séparation des préoccupations etc.

— Jon Skeet

121

Variables de classe (statiques): d'abord les variables de classe publiques, puis les variables protégées et enfin privées.
Variables d'instance: d'abord publique, puis protégée, puis privée.
Constructeurs
Méthodes: ces méthodes doivent être regroupées par fonctionnalité plutôt que par étendue ou accessibilité. Par exemple, une méthode de classe privée peut se trouver entre deux méthodes d'instance publique. Le but est de faciliter la lecture et la compréhension du code.

Source: http://www.oracle.com/technetwork/java/codeconventions-141855.html

— Michael
source

4

Il a 15 ans et probablement un peu dépassé avec l'apparition des IDE modernes ...

— Assylias

16

@assylias: IMO, la lisibilité est indépendante de l'IDE. Il est généralement préférable de garder public avant privé.

— saurabheights

40

Le lien plus précis vers «Conventions de code»: «Déclarations de classe et d'interface»

— Timofey Gorshkov
source

8

+1, afaik - c'est le SEUL article qui répond réellement à la question. OUI, il existe un ordre standard tel que dicté par Oracle et Sun: 1. commentaire public, 2. classe, 3. commentaire interne, 4. données statiques, 5. données d'instance, 6. ctors, 7. méthodes et dans chaque groupe de sections logiquement, pas par accessibilité.

— John Henckel

@VadimKirilchuk «Internet Archive» était en panne…

— Timofey Gorshkov

1

oracle.com/technetwork/java/codeconvtoc-136057.html

— Elder Geek

15

Je ne sais pas s'il existe une norme universellement acceptée, mais mes propres préférences le sont;

les constructeurs d'abord
méthodes statiques ensuite, s'il y a une méthode principale, toujours avant les autres méthodes statiques
méthodes non statiques ensuite, généralement dans l'ordre de la signification de la méthode suivie de toutes les méthodes qu'elle appelle. Cela signifie que les méthodes publiques qui appellent d'autres méthodes de classe apparaissent vers le haut et les méthodes privées qui n'appellent aucune autre méthode finissent généralement vers le bas
méthodes standard comme toString, equalset hashcodeensuite
les getters et les setters ont une place spéciale réservée en bas de la classe

— Qwerky
source

Je préfère vraiment que les constructeurs durent car un constructeur correctement écrit ne devrait pas faire autre chose que d'assigner ses arguments aux propriétés.

— GordonM

@GordonM Pourquoi pensez-vous cela? J'irais jusqu'à dire que l'inverse est vrai. Vous devez toujours penser à l'API la plus propre pour vos classes. Et ce n'est souvent pas la façon dont ils sont stockés, donc je fais souvent pas mal de traitement pour soulager l'appelant de ce fardeau

— Neuron

@GordonM Je ne parle pas d'effets secondaires. Donc, pas de changements aux listes qui ont été passées ou quoi que ce soit de semblable. Le simple fait de passer et de définir des valeurs nécessite que la classe vous en dise beaucoup sur son implémentation, ce qui ne devrait pas être le cas

— Neuron

@LonelyNeuron Je ne suis pas tout à fait sûr de ce que vous dites ici, mais il semble que vous dites que le constructeur devrait faire beaucoup de travail de configuration autre que d'assigner ses arguments à l'état interne. C'est très certainement faux, car cela signifie que les choses se passent par «magie». Un appel à new Thing()ne doit aboutir qu'à l'instanciation d'une nouvelle chose. Cela ne devrait pas entraîner l'ouverture de connexions à la base de données, l'écriture de fichiers, etc.

— GordonM

@LonelyNeuron Avoir des dépendances dans un constructeur ne vous dit rien sur l'implémentation de la classe autre que ses dépendances. C'est une bonne chose, pas une mauvaise.

— GordonM

12

40 méthodes dans une seule classe, c'est un peu beaucoup.

Serait-il judicieux de déplacer une partie des fonctionnalités dans d'autres classes - correctement nommées? Ensuite, il est beaucoup plus facile de comprendre.

Lorsque vous en avez moins, il est beaucoup plus facile de les répertorier dans un ordre de lecture naturel. Un paradigme fréquent est de lister les choses avant ou après que vous en ayez besoin, dans l'ordre où vous en avez besoin.

Cela signifie généralement que cela main()va en haut ou en bas.

— Thorbjørn Ravn Andersen
source

1

vous avez si raison - ce n'est pas un problème de commande

— kostja

4

Vous n'avez pas toujours le choix, par exemple si vous implémentez une interface avec de nombreuses méthodes.

— finnw

5

Ceci est une activité Android, donc il y a beaucoup qui ne peuvent tout simplement pas aller nulle part ailleurs, onPause(), onResume()etc., ainsi que tous mes OnClickListenerchamps, qui, bien qu'ils sont des champs, ne regardez pas ou qui se comportent comme eux il est donc judicieux de listez-les séparément.

— fredley

@finnw, les classes abstraites sont agréables et utilisables dans ce but.

— Thorbjørn Ravn Andersen

11

Ma "convention": statique avant instance, public avant privé, constructeur avant méthodes, mais méthode principale en bas (si présente).

— Eljenso
source

2

De plus, eclipse offre la possibilité de trier les membres de la classe pour vous, si vous les avez mélangés pour une raison quelconque:

Ouvrez votre fichier de cours, allez dans "Source" dans le menu principal et sélectionnez "Trier les membres".

tiré d'ici: Méthodes de tri dans Eclipse

— Stéphan Richter
source

1

Utilisez-vous Eclipse? Si tel est le cas, je m'en tiendrai à l'ordre de tri des membres par défaut, car celui-ci sera probablement le plus familier à celui qui lit votre code (bien que ce ne soit pas mon ordre de tri préféré).

— finnw
source