Le comportement de finale de la méthode statique

J'ai été jouer avec des modificateurs avec la méthode statique et est venu à travers un comportement bizarre.

Comme nous le savons, les méthodes statiques ne peuvent pas être remplacées, car elles sont associées à une classe plutôt qu'à l'instance.

Donc, si j'ai l'extrait de code ci-dessous, il compile des beaux -

//Snippet 1 - Compiles fine
public class A {
    static void ts() {
    }
}

class B extends A {
    static void ts() {
    }
}

Mais si je comprend finale modificateur méthode statique dans Une classe, puis la compilation échoue
ts() dans B ne peut pas remplacer ts() dans Une; méthode de remplacement est statique final.

Pourquoi est-ce qui se passe lorsque la méthode statique ne peut pas être substituée à tous?

il semble bizarre, +1 pour la question, mais jusqu'à présent, aucun des réponses satisfaisantes.
Ce n'est pas remplacée. Il est toujours là à A. ts().

InformationsquelleAutor Harish | 2009-11-16

152

Méthodes statiques ne peuvent pas être remplacés, mais ils peuvent être cachés. Le ts() méthode de B n'est pas primordiale(qui ne font pas de polymorphisme) le ts() d'Un, mais il va le cacher. Si vous appelez ts() dans B (PAS A.ts() ou B.ts() ... juste ts()), l'un des B sera appelée, et pas A. Puisque ce n'est pas l'objet de polymorphisme, l'appel ts() dans Une volonté de ne jamais être redirigé vers celui de B.

Le mot-clé final va désactiver la méthode d'être caché. Ils ne peuvent donc pas être cachés et de tenter de le faire se traduira par une erreur du compilateur.

Espère que cette aide.
- Peut-être la finition de votre réponse, qui est juste, je crois, le problème ici est fondamentalement un mauvais message d'erreur du compilateur: il faut, dit-B ne peut pas masquer ts() dans A. la déclaration d'une méthode statique final est de déclarer qu'il ne peut être cachée.
- Owen: je le pense aussi. Le terme de "cacher" est même utilisé dans la Spécification de Java alors pourquoi ne pas l'utiliser dans le compilateur message.
- Pourquoi est-ce même une fonctionnalité? Dans ce contexte, serait-il utile?
- public class Test { final static public void main(String... srik) { System.out.println("Dans la méthode main"); ts(); } public static void ts() { Enfant c=new Fille(); c.ts(); System.out.println("Test ts"); } } public class Enfant s'étend Test { public static void ts() { System.out.println("Enfant ts"); } } Hi u Peut plz m'expliquer ce qui se passe dans ce scénario
- Je ne pense pas que c'est correct non plus, le compilateur doit dire que depuis A#ts est héréditaire, et une telle méthode existe déjà dans B, il suffit d'avoir deux méthodes avec la même signature et un autre modificateur (final) ne fonctionnerait pas que les surcharges... je souhaite que je pourrais croire à un simple message pour cela, mais
InformationsquelleAutor NawaMan
12

méthodes statiques ne peuvent pas être redéfinies

Ce n'est pas exactement vrai. L'exemple de code vraiment signifie que la méthode ts en B masque la méthode ts en A. Donc ce n'est pas exactement primordial. Plus sur Javaranch il y a une bonne explication.
- Il est vrai tout simplement pas exacte. les méthodes statiques ne peuvent pas être remplacés, mais peut être masqué si vous appelez sur une instance de référence plutôt que le nom de la classe.
- Malheureusement, votre lien ne fonctionne pas plus. Est-il possible de résoudre ce problème?
- Le javaranch lien ne fonctionne pas, mais une recherche sur Google les mots-clés activé ce lien sur le code ranch
- J'ai édité le post de remplacer le lien mort par le lien posté par Sundeep.
InformationsquelleAutor Vincent Ramdhanie
10

Méthodes statiques appartiennent à la classe, et non l'instance.

A.ts() et B.ts() sont toujours des méthodes distinctes.

Le vrai problème est que Java vous permet d'appeler des méthodes statiques sur une instance d'objet. Méthodes statiques avec la même signature de la classe parent sont caché lorsqu'il est appelé à partir d'une instance de la sous-classe. Cependant, vous ne pouvez pas remplacer/masquer finale méthodes.

Vous pensez que le message d'erreur serait d'utiliser le mot caché au lieu de substituée...

InformationsquelleAutor Powerlord
5

Vous pourriez vous retrouver dans la position de penser à faire une méthode static final, tenant compte des éléments suivants:

Avoir les classes suivantes:
```
class A {
    static void ts() {
        System.out.print("A");
    }
}
class B extends A {
    static void ts() {
        System.out.print("B");
    }
}
```
Maintenant la "bonne" façon d'appeler ces méthodes pourraient être
```
A.ts();
B.ts();
```
qui aurait pour résultat AB mais vous pouvez aussi appeler des méthodes sur les instances:
```
A a = new A();
a.ts();
B b = new B();
b.ts();
```
qui aurait pour résultat AB ainsi.

Maintenant, considérez les points suivants:
```
A a = new B();
a.ts();
```
ce serait imprimer A. Qui pourrait vous surprendre, puisque vous sont effectivement avoir un objet de la classe B. Mais puisque vous êtes en l'appelant à partir d'une référence de type A, il va appeler A.ts(). Vous pouvez imprimer B avec le code suivant:
```
A a = new B();
((B)a).ts();
```
Dans les deux cas, l'objet est en fait de classe B. Mais selon le pointeur qui pointe sur l'objet, vous devez appeler la méthode de A ou de B.

Maintenant, disons que vous êtes le développeur de la classe A et vous souhaitez autoriser les sous-classement. Mais vous voulez vraiment méthode ts(), à chaque fois appelé, même à partir d'une sous-classe, c'est-à fait ce que vous voulez faire et de ne pas être cachés par une sous-version. Ensuite, vous pouvez le faire final et l'empêcher d'être caché dans la sous-classe. Et vous pouvez être sûr que le code suivant va appeler la méthode à partir de votre classe A:
```
B b = new B();
b.ts();
```
Ok, admittetly qui est en quelque sorte construit, mais il peut faire sens pour certains cas.

Vous ne devriez pas appeler des méthodes statiques sur les instances, mais directement sur les classes - alors vous n'aurez pas ce problème. Aussi IntelliJ IDEA pour exemple va vous montrer un avertissement, si vous appelez une méthode statique sur une instance et ainsi si vous faites une méthode statique finale.

InformationsquelleAutor Mathias Bader
1

Je pense que l'erreur de compilation est tout à fait trompeur ici. Il ne devrait pas avoir dit "méthode surchargée est statique de la finale.", mais il devrait plutôt avoir dit "méthode de remplacement est définitif.". Le modificateur static est pas pertinente ici.
- Si vous considérez la méthode statique dans B en substituant l'un à Un?
- Je me demande juste si le compilateur regarde d'abord le éventuellement méthode remplaçable (ignore statique pour un moment), voit finale à l'échec. Juste une supposition bien sauvage
- Balus je pense que c'est le seul de la faible qualité de réponse que vous avez dans StackOverflow. Compte tenu de tous vos exceptionnelles réponses, celui-ci ne leur appartiennent pas. @BalusC
- à l'époque, je n'avais pas assez de réputation pour le commentaire 🙂 Si vous exécutez la commande ping de retour, je vais supprimer la réponse, pas de problème.
InformationsquelleAutor BalusC
0

Le ts() méthode B n'est pas primordial, le ts() la méthode en Un, c'est tout simplement une autre méthode. La classe B ne voit pas le ts() la méthode en A, car il est statique, donc il peut déclarer sa propre méthode appelée ts().

Cependant, si la méthode est définitive, alors le compilateur va ramasser ce qu'il y a un ts() méthode qui ne doit pas être remplacée dans les B.
- Je ne pense pas que c'est ce qui explique pourquoi "final" signifie tout d'un coup ces méthodes ne peuvent pas coexister. Comme vous le dites, sans "final", il n'y a pas de problème. Vous dites que c'est pas primordial, mais alors dites-le problème, c'est que B ne peut pas remplacer Une méthode.
- Il ne vous, je déclare que B ne voit pas la méthode ts() dans Un (il est "caché"), mais au final, le modificateur de ne pas "cacher" les méthodes de classes qui étendent un autre. Mais hein, ok.
InformationsquelleAutor amischiefr
0

Une méthode statique ne peut pas être remplacée dans Java, contrairement à la non-méthodes statiques.
Mais ils sont hérités comme statique et non des données membres statiques. C'est pourquoi un non-statique méthode avec le même nom ne peut pas être créé dans la classe parent
```
class Writer { 
    public static void doo(){
        System.out.println("sth");
    } 
}
class Author extends Writer{ 
    public void doo(){
        System.out.println("ok"); //error overridden method is static
    }
}
```
La final mot-clé veille à ce que le corps de la méthode exécuter à chaque fois un appel à la méthode.
Maintenant, si une méthode statique est créé dans la classe enfant avec le même nom et un appel à la méthode, la méthode de la sous-classe est exécuté qui ne devrait pas être le cas si le final est le préfixe devant le nom de la méthode statique de la classe parent. D'où le mot-clé final restreint la création de la méthode avec le même nom dans la classe enfant.

InformationsquelleAutor Pratik Gupta

Vous devez vous connecter pour publier un commentaire.