Méthodes statiques fonctionnant sur des champs d'instance

Question

J'ai vu des méthodes statiques écrites (mais je n'ai jamais exécuté le code) qui utilise des données d'instance d'une autre classe (instance based).

Habituellement, les données d'instance fonctionnent avec des méthodes d'instance et de même pour les champs/méthodes statiques. Quelle est l'implication de travailler sur des données statiques dans une méthode d'instance? Je suppose que c'est mal vu, mais je ne peux pas trouver de détails sur ce qui se passera sous le capot. En outre, qu'en est-il des méthodes d'instance travaillant avec des données statiques?

Merci

Answer 1

Lorsque vous travaillez avec des données statiques dans une méthode d'instance, la seule implication à laquelle je peux penser est la synchronisation dans une application multithread. Je ne peux pas penser à des implications négatives lorsque vous travaillez avec des données d'instance d'une méthode statique. Cependant, juste parce que quelque chose peut être fait ne signifie pas devrait être fait.

Voici un exemple concret que vous avez fourni.

classe A est une instance basée et a un champ d'instance appelé ProductPrice de double. La classe B est statique et possède une méthode statique appelée PlayAroundWithPrice (double prix) et le codeur est transmis dans le champ ProductPrice .

De toute évidence, il n'y a rien techniquement illégal avec cet exemple, mais il va à l'encontre du grain pour moi. Tout d'abord, le champ ProductPrice de la classe A est évidemment public puisque la classe B peut fonctionner dessus. Pour les besoins de l'encapsulation, je rends toujours les champs privés et j'utilise une propriété publique pour y accéder. Deuxièmement, étant donné que ProductPrice est un champ public au lieu d'une propriété publique, il est impossible pour Class A d'empêcher ProductPrice d'être défini sur des valeurs non valides (valeurs négatives, par exemple). Troisièmement (comme indiqué ci-dessus), si cet exemple se produit dans un programme multithread, il peut y avoir des problèmes de synchronisation. Quatrièmement, je suppose que c'est le vrai problème, pourquoi avoir une méthode statique sur la classe B pour fonctionner sur le terrain de la classe A? Pourquoi ne pas mettre la méthode statique sur la classe A? Je ne sais pas si j'irais aussi loin que d'en faire une règle stricte (peut-être simplement une règle empirique), mais je limiterais l'utilisation de méthodes statiques pour quand vous ne voulez pas pour payer le coût de construction d'un objet juste pour utiliser la méthode.

Par exemple, dans le projet sur lequel je travaille, j'ai une classe IPHeader qui construira entièrement une instance d'IPHeader à partir d'un tampon d'octets. Cependant, dans la plupart des cas, je n'ai besoin que de quelques valeurs de l'IPHeader. Donc, pour éviter les coûts associés à la création et à la collecte des ordures d'une instance d'IPHeader, j'ai ajouté quelques méthodes statiques qui extraient directement les valeurs du tampon d'octets.

J'espère avoir bien compris votre question.

Answer 2

Fondamentalement, les méthodes d'instance a un paramètre this caché qui est utilisé pour transmettre l'instance la méthode est censé travailler. C'est la raison pour laquelle les méthodes statiques ne peuvent pas accéder aux données d'instance sans référence explicite (car elles ne peuvent pas savoir à quelle instance de l'objet elles doivent accéder). Compte tenu de cela, je ne vois pas de différence particulière entre les méthodes statiques et les méthodes d'instance. Ils sont les deux méthodes et a plus de similitudes que de différences.

Les données statiques et les données d'instance sont sujettes à des problèmes de thread, mais les instances sont beaucoup moins susceptibles d'être utilisées entre les threads. Par conséquent, l'accès aux champs statiques peut nécessiter plus de soin (en ce qui concerne les problèmes de synchronisation).

Answer 3

Je ne vois aucun problème à travailler sur les données d'instance d'un autre objet dans une méthode statique.

Je suppose que vous voulez dire, par exemple, passer la variable d'instance d'un objet à une méthode statique via un paramètre, et cette méthode travaille alors sur cette variable.

statique signifie simplement que vous ne recevez pas cette , mais vous pouvez obtenir otherobject-> quelque chose

Je ne pense pas que ce serait plus mal vu que juste en utilisant une méthode statique serait en premier lieu.

Answer 4

Il ne devrait pas y avoir de problème. Récemment j'ai eu un scénario où j'avais besoin que chaque instance d'une classe ait une graine aléatoire différente, mais reproductible. J'ai gardé un int static privé dans la classe, et l'ai incrémenté pour chaque instanciation, et l'ai utilisé comme graine.

Cela a bien fonctionné.

Answer 5

Je ne pense pas que l'utilisation de données statiques dans une méthode d'instance ait intrinsèquement un problème, mais je pense que vous devez vraiment limiter les types de données que vous utilisez. L'avantage/désavantage de cette approche est qu'un seul changement de données peut modifier le comportement de tous les objets d'un type particulier. Cela rend la modification de ce type de données très risquée. J'ai tendance à limiter les utilisations de ce aux scénarios suivants

1. valeurs Immuable - Rien ne peut changer donc il n'y a rien à craindre
2. Objets globaux - Je fortement se abstenir de le faire, mais je l'ai trouvé que parfois, les inconvénients d'avoir un objet global l'emportent sur les risques. Ces objets sont soigneusement surveillés et fortement testés.

Answer 6

Il n'y a aucun problème si une méthode statique utilise des instances d'objet ou une méthode d'instance utilisant des données statiques.

Le framework est plein de méthodes qui le démontrent. La méthode String.Concat très couramment utilisée est par exemple une méthode statique qui prend une ou plusieurs instances d'objet. (Un appel de méthode Concat est ce que le compilateur produit lorsque vous utilisez l'opérateur + pour concaténer des chaînes.)

La propriété Int32.MaxValue est une propriété statique, il n'y a évidemment aucun problème à l'utiliser dans une méthode d'instance.