Pourquoi pouvons-nous accéder à une variable statique via une référence d'objet en Java, comme le code ci-dessous?
6 Réponses :
Les variables statiques sont par ailleurs appelées variables de classe, car elles sont disponibles pour chaque objet de cette classe.
Au fur et à mesure que le membre est un objet de la classe statique, vous pouvez donc accéder à toutes les statiques comme des variables non statiques de classe statique via un objet membre.
Ne répond pas à la question, pas qu'il y ait une réponse.
Ce n'est pas la meilleure pratique de faire référence à une variable statique de cette façon.
Cependant, votre question était la raison pour laquelle est-il autorisé? Je suppose que la réponse est à ce qu'un développeur peut modifier un membre d'instance (champ ou variable) à un membre statique sans avoir à modifier toutes les références à ce membre.
Ceci est particulièrement vrai dans les environnements multi-développeurs. Sinon, votre code peut ne pas compiler simplement parce que votre partenaire a modifié des variables d'instance vers des variables statiques.
Faire une variable d'instance statique doit pour causer des erreurs de compilation. C'est une faille de conception non une caractéristique que de tels changements échouent à l'ondulation en aval.
En règle générale, les variables publiques sont accessibles par tout le monde et les variables privées ne peuvent être accédées qu'à partir de l'instance actuelle de la classe. Dans votre exemple, vous êtes autorisé à accéder à la variable Si vous vous demandez pourquoi vous êtes autorisé à y accéder à une autre instance de classe statique que celle que vous êtes actuellement (ce qui n'est généralement pas autorisé pour les variables privées), c'est simplement parce que les variables statiques ne font pas existent sur une base par instance, mais par classe. Cela signifie que la même variable statique de a est accessible de toutes les instances de a .
Si ce n'était pas le cas, personne ne serait capable d'accéder à la variable statique privée du tout, car elle n'appartient pas à une instance , mais toutes. x à partir de la méthode principale de , car cette méthode est dans la classe statique.
L'élément non statique est membre d'instance. Le membre statique (classe large) n'a pas pu accéder aux membres de l'instance car, il n'existe aucun moyen de déterminer quelle instance possède des membres spécifiques non statiques.
L'objet d'instance pourrait toujours faire référence aux membres statiques car il appartient à la classe que mondiale (partagée) à ses instances.
La raison pour laquelle il est autorisé est que le JLS dit que c'est. Les sections spécifiques qui permettent de cela sont JLS 6.5.6.2 (pour le Si le champ est statique:
Si le champ est un champ final non vide, le résultat est la valeur de la variable de classe spécifiée dans la classe ou l'interface qui correspond au type de l'expression primaire.
Si le champ n'est pas final, une finale vierge et l'accès au champ se produit dans une variable de classe variable (§8.3.2) ou initialisateur statique (§8.7), le résultat est une variable, à savoir , la variable de classe spécifiée dans la classe qui est le type de l'expression primaire.
Pourquoi ceux-ci sont-ils autorisés par les JLS?
Franchement, je ne sais pas. Je ne peux penser à de bonnes raisons de les autoriser.
de toute façon, en utilisant une référence ou Dans vos premier et deuxième cas, vous devez faire référence à la variable sous forme membre.x cas) et JLS 15.11.1 (dans les deux cas). Ce dernier dit:
ce pour accéder à une variable statique est une mauvaise idée, car la plupart des programmeurs sont susceptibles d'être induits en erreur pour penser que vous utilisez une instance champ. C'est une raison forte de ne pas utiliser cette caractéristique de Java.
x ou static.x plutôt que membre.x . (Je préfère static.x .)
se mettre d'accord. Et je tiens à souligner explicitement que d'utiliser membre.x ou ceci.x , bien que cela ne recommande pas du tout, reste viable et n'aura aucune erreur de compilation.
Merci pour le commentaire. Cependant, je ne pense pas que cela ait besoin d'en souligner plus; La réponse acceptée fait un bon travail. Quoi qu'il en soit, la question est " pourquoi est-elle autorisée", pas "est-ce autorisée".
Cela donne logiquement bien que ce ne soit pas une pratique intéressante. La variable statique est généralement destinée à appliquer une déclaration unique de variable lors de l'instanciation. L'objet est une nouvelle copie de la classe avec un autre nom. Même si l'objet est une nouvelle copie de la classe, il est toujours caractérisé par des caractéristiques de la classe (instantanée) (première instance invisible). Par conséquent, le nouvel objet présente également que les membres statiques pointant vers la copie originale. Chose à noter est: une nouvelle instance de Stackoverflow est également Stackoverflow.
Et l'objet n'est pas une "copie" d'une classe et il n'y a pas de "pointant vers la copie originale". Les champs statiques ne sont pas réellement stockés dans une instance de la classe. Ils sont stockés ailleurs. (Où? Mise en œuvre Spécifique!) En gros, vous attachez d'expliquer la sémantique JLS basée sur un modèle mental incorrect de la mise en œuvre de la statique d'une JVM.
Vous pouvez également faire static.x Pas besoin de créer un objet.
IIRC, Josh Bloch a déclaré que l'autorisation de c'était une mauvaise décision.