Quand utiliser une variable d'instance d'objet par rapport à la transmission d'un argument à la méthode

Comment décidez-vous entre passer des arguments à une méthode et simplement les déclarer en tant que variables d'instance d'objet visibles par toutes les méthodes de l'objet?

Je préfère garder les variables d'instance dans une liste à la fin de la classe, mais cette liste s'allonge à mesure que mon programme se développe. Je pense que si une variable est transmise assez souvent, elle devrait simplement être visible par toutes les méthodes qui en ont besoin, mais je me demande alors "si tout est public, il ne sera pas nécessaire de passer quoi que ce soit!"

Puisque vous faites référence aux variables d'instance, je suppose que vous travaillez dans un langage orienté objet. Dans une certaine mesure, quand utiliser des variables d'instance, comment définir leur portée et quand utiliser des variables locales est subjectif, mais il existe quelques règles empiriques que vous pouvez suivre chaque fois que vous créez vos classes.

• Les variables d'instance sont généralement considérées comme des attributs d'une classe. Considérez-les comme des adjectifs de l'objet qui sera créé à partir de votre classe. Si vos données d'instance peuvent être utilisées pour aider à décrire l'objet, alors il est probablement prudent de parier que c'est un bon choix pour les données d'instance.

• Les variables locales sont utilisées dans le cadre des méthodes pour les aider à terminer leur travail. Habituellement, une méthode doit avoir pour but d'obtenir des données, de renvoyer certaines données et / ou de traiter / d'exécuter un algorithme sur certaines données. Parfois, il est utile de penser aux variables locales comme des moyens d'aider une méthode à avancer du début à la fin.

• La portée de la variable d'instance n'est pas seulement pour la sécurité, mais également pour l'encapsulation. Ne partez pas du principe que «l'objectif devrait être de garder toutes les variables privées». En cas d'héritage, rendre les variables protégées est généralement une bonne alternative. Plutôt que de marquer toutes les données d'instance comme publiques, vous créez des getters / setters pour ceux qui doivent être accédés au monde extérieur. Ne les rendez pas tous disponibles - uniquement ceux dont vous avez besoin. Cela se produira tout au long du cycle de vie du développement - c'est difficile à deviner dès le départ.

Lorsqu'il s'agit de transmettre des données à une classe, il est difficile de dire que ce que vous faites est une bonne pratique sans voir du code. Parfois, opérer directement sur les données de l'instance est très bien; d'autres fois, ce n'est pas le cas. À mon avis, c'est quelque chose qui vient avec l'expérience - vous développerez une certaine intuition au fur et à mesure que vos capacités de réflexion orientée objet s'amélioreront.

Cela dépend principalement de la durée de vie des données que vous stockez dans la variable. Si les données ne sont utilisées que lors d'un calcul, transmettez-les en paramètre. Si les données sont liées à la durée de vie de l'objet, utilisez une variable d'instance.

Lorsque votre liste de variables devient trop longue, c'est peut-être un bon point de penser à refactoriser certaines parties de la classe dans une nouvelle classe.

À mon avis, les variables d'instance ne sont nécessaires que lorsque les données seront utilisées à travers les appels.

Voici un exemple:

myCircle = myDrawing.drawCircle(center, radius);

Maintenant, imaginons que la classe myDrawing utilise 15 fonctions d'assistance pour créer l'objet myCircle et chacune de ces fonctions aura besoin du centre et du rayon. Ils ne doivent toujours pas être définis comme variables d'instance de la classe myDrawing. Parce qu'ils ne seront plus jamais nécessaires.

D'autre part, la classe myCircle devra stocker à la fois le centre et le rayon en tant que variables d'instance.

myCircle.move(newCenter);
myCircle.resize(newRadius);

Pour que l'objet myCircle sache quel est son rayon et son centre lorsque ces nouveaux appels sont effectués, ils doivent être stockés en tant que variables d'instance, et pas seulement transmis aux fonctions qui en ont besoin.

Donc, fondamentalement, les variables d'instance sont un moyen de sauvegarder "l'état" d'un objet. Si une variable n'est pas nécessaire pour connaître l'état d'un objet, alors ce ne devrait pas être une variable d'instance.

Et comme pour tout rendre public. Cela pourrait vous faciliter la vie sur le moment. Mais il reviendra vous hanter. Ne vous en faites pas.

A MON HUMBLE AVIS:

Si la variable fait partie de l'état de l'instance, alors il doit s'agir d'une variable d'instance - classinstance HAS-A instancevariable.

Si je me retrouvais à passer quelque chose à plusieurs reprises dans les méthodes d'une instance, ou si je découvrais que j'avais un grand nombre de variables d'instance, j'essaierais probablement de regarder ma conception au cas où j'aurais manqué quelque chose ou fait une mauvaise abstraction quelque part.

J'espère que ça aide

Bien sûr, il est facile de conserver une grande liste de variables publiques dans la classe. Mais même intuitivement, vous pouvez dire que ce n'est pas la voie à suivre.

Définissez chaque variable juste avant de l'utiliser. Si une variable prend en charge la fonction d'une méthode spécifique, utilisez-la uniquement dans le cadre de la méthode.

Pensez également à la sécurité, une variable de classe publique est sensible aux modifications indésirables du code «extérieur». Votre objectif principal devrait être de garder toutes les variables privées, et toute variable qui ne l'est pas devrait avoir une très bonne raison de l'être.

À propos du passage des paramètres tout au long de la pile, cela peut devenir très rapide. Une règle de base est de garder vos signatures de méthode propres et élégantes. Si vous voyez de nombreuses méthodes utilisant les mêmes données, décidez si c'est suffisamment important pour être un membre de classe, et si ce n'est pas le cas, refactorisez votre code pour qu'il ait plus de sens.

Cela revient au bon sens. Pensez exactement où et pourquoi vous déclarez chaque nouvelle variable, quelle doit être sa fonction, et à partir de là, décidez dans quelle portée elle doit vivre.