Vous préférez les membres de la classe ou la transmission d'arguments entre méthodes internes?

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

D'un côté, je pourrais voir un argument selon lequel la réduction de l'état (c'est-à-dire des 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 en tant qu'état pour que la classe rende le code visiblement plus propre, si rien d'autre.

Modifier:

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

Ignorant un instant l'angle de la POO, le cas d'utilisation particulier que j'avais à l'esprit était le suivant (supposons passe 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 à plusieurs fonctions - dans le cas que j'avais en tête, cela était dû à l'enchaînement de fonctions plus petites. Dans un système OOP, s'il s'agissait de toutes les méthodes d'une classe (par exemple, en raison d'un refactoring via l'extraction de méthodes à partir d'une méthode large), cette variable pourrait être transmise à toutes ou à un membre de la classe.

Si la valeur est une propriété de la classe, conservez-la dans la classe, sinon, conservez-la à l'extérieur. Vous ne concevez pas vos méthodes de classe. D'abord, vous concevez d'abord ses propriétés. Si vous n'avez pas envisagé de placer cette propriété à l'intérieur de la classe, il y a probablement une raison à cela.

La pire chose à faire, en termes d'évolutivité, est de modifier votre code pour plus de commodité. Le plus tôt possible, vous constaterez que votre code est gonflé et dupliqué. Cependant, je dois avouer que parfois je ne respecte pas cette règle ... La commodité est tellement attrayante.

Si vous n'avez pas réellement besoin de maintenir l'état entre les invocations (et apparemment vous ne le faites pas, sinon 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 at la signature de la méthode vous indique qu'elle 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. De plus, il n’est pas toujours rapide de déterminer à quoi servent les variables de membre privé.

Donc, normalement, je ne serais pas d'accord pour dire que le code utilisant des variables membres est visiblement plus propre, mais si les signatures de la méthode deviennent incontrôlables, je pourrais faire une exception. C'est une question intéressante, mais le projet ne dépendra en aucun cas de ce projet.

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

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

• c'est plus facile à tester -> plus facile à maintenir (par rapport au dernier point)
• n'a pas d'effets secondaires
• c'est plus facile à comprendre

Par exemple, je vois clairement ce que vous voulez dire. Par exemple, vous analysez un document Excel (à l’aide de la bibliothèque de POI, par exemple). Au lieu de transmettre une instance de ligne à chaque méthode devant fonctionner avec cette ligne, author a une variable membre currentRowet fonctionne avec elle.

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

Peut-être devriez-vous 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 à des fins de test.

Si vous avez deux ou plusieurs temporaries qui sont toujours passés ensemble, alors vous devriez certainement extraire une nouvelle classe.

Les gens préfèrent-ils définir cette variable en tant que variable membre de la classe ou la transmettre en tant qu'argument à chacune des méthodes - et pourquoi?

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

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

Il n'y a rien de mal à déclarer une private static finalconstante pour définir des constantes. Le compilateur pourra utiliser cette valeur en considérant certaines optimisations, et étant des constantes, ils 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 ...

Le fait de pouvoir s'y référer de manière symbolique (par exemple, BLRFL_DURATION) et de ne pas avoir à ajouter d'arguments supplémentaires à vos méthodes rendra votre code plus lisible et donc plus facile à gérer.

si la valeur ne change pas, il s'agit par définition d'une constante et doit être encapsulé dans la classe. Dans ce cas, il n'est pas considéré que cela affecte 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 risquez d'exposer le résultat à une erreur si le client transmet la mauvaise valeur ou une valeur qui n'a pas la même précision que celle attendue par la ou les méthodes.