En bref, vous surchargez la signification prévue du terme "overriding" en Java :-).
Imaginons que quelqu'un d'autre ait écrit le Animal (en la réécrivant légèrement, sans changer la sémantique, mais pour démontrer une bonne pratique). Nous supposerons également que Animal compile et fonctionne bien :
public class Animal {
public static void main(String args[]) {
Animal a = new Animal(); // yes, Animal, no Horse yet.
a.eat();
}
///// Animal's private methods, you should not look here
private void eat() {
System.out.println("animal eating");
}
///// Animal's private methods, you should not look here
}
Il s'agit d'une bonne pratique de codage Java, car l'auteur de l'article Animal ne veut pas que vous, le lecteur de ce code, sachiez vraiment quoi que ce soit sur Animal de l'entreprise privée.
Ensuite, vous regardez le public static void main méthode de Animal et déduire correctement qu'il existe une méthode nommée eat() qui y sont définis. A ce stade, ce qui suit est valable :
- Comme toute autre classe en Java,
Animal étend Object .
- Vous regardez les méthodes publiques (et protégées) de l'application
Object et découvrir qu'il n'existe pas de méthode telle que eat() . Étant donné que Animal compile bien, vous pouvez en déduire que eat doivent être Animal Les affaires privées de l'UE ! Il n'y a pas d'autre moyen pour que Animal pourrait compiler. Ainsi, sans regarder Animal Vous pouvez en déduire qu'il y a un lien entre l'entreprise privée et l'entreprise privée. eat() méthode dans Animal classe qui est privé !
Disons maintenant que votre intention était de créer un autre animal nommé Horse en tant que spécialiste Animal et lui donner un comportement spécial de manger. Vous vous dites que vous êtes pas va regarder dans Java Lang Spec et trouver toutes les règles pour le faire et juste utiliser la extends mot-clé et en finir avec lui. La première version de Horse puis émerge. Vous avez cependant entendu quelque part qu'il est préférable de clarifier votre intention de Remplacement de (c'est une chose dont vous êtes maintenant certain -- vous voulez vraiment contourner eat comportement des Horse ) :
class Horse extends Animal {
@Override
public void eat() {
System.out.println("Horse eating");
}
}
Exact ; vous ajoutez la balise @Override . C'est toujours une bonne idée, certes, à un verbiage accru (C'est une bonne pratique pour quelques raisons que nous ne détaillerons pas ici).
Vous essayez de compiler Horse.java et vous voyez :
Error:(21, 5) java: method does not override or implement a
method from a supertype
Ainsi, le compilateur qui connaît le langage de programmation Java mieux que nous, nous dit que nous sommes, en fait, pas en passant outre ou mise en œuvre de une méthode qui est déclarée dans un supertype .
Maintenant, la manipulation des surcharges en Java devient plus claire pour nous. Puisque nous sommes censés ne remplacer que les comportements conçus pour être remplacés, à savoir les méthodes publiques et protégées, nous devons faire attention à la façon dont les superclasses sont écrites. Dans ce cas, par inadvertance, la superclasse Animal qui a été apparemment conçu pour l'extension, rendait impossible pour les sous-classes de remplacer l'option de l'utilisateur. eat comportement !
Même si nous avons retiré le @Override En effet, comme vous l'avez observé, au moment de l'exécution, la méthode involontaire dont la signature correspond est appelée. C'est encore pire.
