web-dev-qa-db-fra.com

Vous préférez les membres de la classe ou passez des arguments entre les méthodes internes?

Supposons que dans la partie privée d'une classe, il existe une valeur qui est utilisée par plusieurs méthodes privées. Les gens préfèrent-ils la définir comme variable membre pour la classe ou la transmettre comme argument à chacune des méthodes - et pourquoi?

D'une part, je pouvais voir un argument avancé selon lequel réduire l'état (c'est-à-dire les variables membres) dans une classe est généralement une bonne chose, bien que si la même valeur est utilisée à plusieurs reprises dans les méthodes d'une classe, il semble que ce serait un idéal candidat à la représentation comme état de la classe pour rendre le code visiblement plus propre si rien d'autre.

Éditer:

Pour clarifier certains des commentaires/questions qui ont été soulevés, je ne parle pas de constantes et cela ne concerne aucun cas particulier, mais juste une hypothèse dont je parlais à d'autres personnes.

Ignorant l'angle OOP pendant un moment, le cas d'utilisation particulier que j'avais en tête était le suivant (supposons passer par référence juste pour rendre le pseudocode plus propre)

int x
doSomething(x)
doAnotherThing(x)
doYetAnotherThing(x)
doSomethingElse(x)

Donc, ce que je veux dire, c'est qu'il y a une variable qui est commune entre plusieurs fonctions - dans le cas où je pensais que c'était dû au chaînage de fonctions plus petites. Dans un système OOP, s'il s'agissait de toutes les méthodes d'une classe (disons en raison de la refactorisation via l'extraction de méthodes d'une grande méthode), cette variable pourrait être passée autour d'elles toutes ou ce pourrait être une classe membre.

javacode-qualityvariablesclass-designmethods
45
geoffjentry

Si la valeur est une propriété de la classe, conservez-la dans la classe. Sinon, gardez-le dehors. Vous ne concevez pas d'abord vos méthodes de classe. Vous concevez d'abord ses propriétés. Si vous n'avez pas pensé à mettre cette propriété à l'intérieur de la classe en premier lieu, il y a probablement une raison à cela.

La pire chose que vous puissiez faire, en termes d'évolutivité, est de changer votre code pour plus de commodité. Tôt, plutôt que tard, vous constaterez que votre code est gonflé et dupliqué. Cependant, je dois admettre. Parfois, j'enfreins cette règle. La commodité est tellement attrayante.

17
AJC

Si vous n'avez pas vraiment besoin de maintenir l'état entre les invocations (et apparemment vous ne le faites pas, ou vous ne poseriez pas la question), je préférerais que la valeur soit un argument plutôt qu'une variable membre, car un coup d'œil rapide à la signature de la méthode vous indique qu'il utilise l'argument, alors qu'il est un peu plus difficile de dire immédiatement quelles variables membres sont utilisées par la méthode. Il n'est également pas toujours rapide de déterminer à quoi servent les variables de membre privé.

Donc, normalement, je ne suis pas d'accord pour dire que le code utilisant des variables membres est visiblement plus propre, mais si les signatures de méthode deviennent incontrôlables, je pourrais faire une exception. C'est une question valable, mais ce n'est pas quelque chose sur quoi le projet reposera de toute façon.

14
psr

Merci d'avoir posé la question, je voulais aussi la poser.

Quand je pensais à cela, il y a quelques avantages à le faire comme argument

  • c'est plus facile à tester -> plus facile à entretenir (lié au dernier point)
  • n'a pas d'effets secondaires
  • c'est plus facile à comprendre

Je vois clairement votre point par exemple - l'un analyse le document Excel (en utilisant la bibliothèque POI par exemple) et au lieu de passer l'instance de ligne à chaque méthode qui doit travailler avec cette ligne, l'auteur a la variable membre currentRow et fonctionne avec il.

Je dirais qu'il devrait y avoir un nom pour cet anti-modèle, n'est-ce pas? (non répertorié ici )

10
Betlista

Vous devriez peut-être extraire une nouvelle classe contenant toutes les méthodes partageant cette valeur. Bien sûr, la méthode de plus haut niveau sera publique dans la nouvelle classe. Il peut être utile d'exposer cette méthode pour les tests.

Si vous avez deux ou plusieurs temporaires qui sont toujours transmis ensemble, vous devriez presque certainement extraire une nouvelle classe.

1
kevin cline

Les gens préfèrent-ils la définir comme variable membre pour la classe ou la transmettre comme argument à chacune des méthodes - et pourquoi?

Si je comprends ce que vous demandez: Les méthodes dans une classe sont par définition au courant des détails d'implémentation, donc je n'aurais aucun scrupule à utiliser un membre directement à partir de n'importe quelle méthode.

D'une part, je pouvais voir un argument à faire valoir que réduire l'état (c'est-à-dire les variables membres) dans une classe est généralement une bonne chose ...

Il n'y a rien de mal à déclarer un private static final pour définir des constantes. Le compilateur pourra utiliser la valeur en considérant certaines optimisations, et étant des constantes, elles n'ajoutent pas vraiment d'état à la classe.

bien que si la même valeur est utilisée à plusieurs reprises dans les méthodes d'une classe ...

Être capable de s'y référer symboliquement (par exemple, BLRFL_DURATION) et ne pas avoir à ajouter d'arguments supplémentaires à vos méthodes rendra votre code plus lisible et donc plus maintenable.

1
Blrfl

si la valeur ne change pas, elle est par définition a constante et doit être encapsulée dans la classe. Dans ce cas, il n'est pas considéré comme affectant l'état d'un objet. Je ne connais pas votre cas mais je pense à quelque chose comme PI en trigonométrie. Si vous essayez de passer un argument d'une telle constante, vous pourriez exposer le résultat à une erreur si le client transmet la mauvaise valeur ou une valeur qui n'est pas avec la même précision que la ou les méthodes attendues.

0
NoChance