8
votes

Pourquoi ne devriez-vous pas accéder à un membre partagé / statique via une variable d'instance?

Voici un exemple de ce dont je parle ... xxx

me.myvalue donne un avertissement dans vb.net et (le code équivalent donne ) une erreur en C #. A-t-il une raison particulière pour ceci? Je trouve plus intuitif / naturel d'accéder à la fonction partagée en utilisant 'Me.myvalue' - mais j'évite qu'il conserve mes avertissements à 0.

Quelqu'un d'autre décida-t-il, il a plus de sens à Faites-le l'inverse »ou existe-t-il une raison technique que je ne comprends pas?

Edit:

Merci tout le monde. Je pensais que cela ne va pas, davantage comme une "sous-classe" dans OOP. Même si quelque chose est déclaré dans la classe de base, vous y accédez à travers l'instance que vous avez. Mais cette relation n'est pas la même avec partagée ou statique.


0 commentaires

6 Réponses :


7
votes

Les membres statiques par définition sont déclarés au niveau Classe , et non au niveau d'instance, et accédez donc à un membre statique à l'aide de Ceci (ou Dans VB) ne se sent pas vraiment bien (et n'est pas juste en C #)

dire ceci.Quelque chose (ou moi.something ) implique que vous accédez à "quelque chose" qui est particulièrement particulier à cette instance spécifique, alors que, à nouveau, les membres statiques sont partagés Toutes les instances de cette classe.


3 commentaires

Cette. La fonction myvalue n'appartient à aucune instance; Il faut donc être accessible en dehors des limites d'une seule instance. Essayer d'utiliser l'équivalent C # de moi.Myvalue entraînerait une erreur de compilateur, alors même si elle est autorisée dans VB, c'est mauvais.


@Keiths - Avez-vous eu l'intention de faire une réponse, ou un commentaire sur ma réponse?


Un commentaire. J'allais dire exactement la même chose que vous l'avez fait, alors je viens de vous avoir jeté et m'a dit mon chemin. :)



2
votes

me code> pointe vers l'instance actuelle forte> de exemple1 code>, tandis que myvalue code> appartient à la catégorie fort> lui-même. Ainsi, il me semble bien que vb.net vous avertit.

Au fait, Java le fait de la même manière: P>

Thread.currentThread().sleep(1000); // warning, as sleep is static
Thread.sleep(1000); // correct


0 commentaires

3
votes

C'est trompeur pour le lecteur de votre code.

Le code doit être écrit pour être lu et compris par un autre programmeur, WO ne connaît pas tous les détails du projet. Accéder à une variable statique via une instance, il ressemble à un membre d'instance - vous devez vérifier la déclaration de voir que vous vous trompez.

Cet "autre programmeur" pourrait aussi bien être vous après une demi-année.


0 commentaires

1
votes

Plus que probablement, le compilateur vous protège de faire une erreur dans le cas où vous avez une instance et un membre statique du même nom. XXX

Résultats: < ul>

  • statique
  • statique
  • instance

  • 0 commentaires

    2
    votes

    Le statique membres / méthodes fonctionne au niveau de la classe (c.-à-d. Comportement indépendant de toute instance d'objet) et membres / méthodes d'objet fonctionne au niveau d'instance , ils ont donc deux identités différentes: - http://msdn.microsoft.com/fr -us / bibliothèque / 79b3xss3 (v = vs.80) .aspx


    0 commentaires

    1
    votes

    Vous ne pouvez pas accéder aux champs de niveau de classe par cette référence et vous ne pouvez pas accéder aux champs de niveau d'objet par référence de classe, il est parfait sens.

    Si vous deviez accéder au champ de niveau de classe par Ce pointeur , vous pouvez vous retrouver avec un code étrange xxx

    ce qui pourrait induire en erreur une personne que nous réellement éditer différentes propriétés ou champs, mais s'ils sont accessibles par nom de classe xxx

    c'est clair que nous étions la même chose.

    aussi dans Les champs statiques de la mémoire sont stockés dans un endroit complètement différent (proche de type objet) que des champs d'objets, donc je pense à sa différence super claire.

    La vraie question est - pourquoi ce n'est pas une erreur dans vb.net. Je devinerais que la réponse est Taht VB héritée de certaines des fonctionnalités anciennes non de type .NET qui n'augmente pas de sécurité très sûre et son résultat étrange d'une telle héritage.


    0 commentaires