importer java.util. *; erreur: nom Clash: La méthode Ajouter (objet) de type Test2 a la même effacement que Ajouter (E) de type hashset, mais pas Remplacez-le Je ne sais pas quel est le concept derrière l'erreur ci-dessus, quelqu'un peut-il suggérer où je peux étudier ce concept?
3 Réponses :
Avez-vous essayé d'utiliser entier au lieu d'objet obj I.e
Le problème est que lorsque vous extensez Hashset, vous étendez-vous entier HashSet et non la forme générique. Donc, dans la sous-classe, votre méthode d'addition doit être conforme à la signature de la méthode de superclasse qui est Boolean public Ajouter (Entier I) {} Si vous souhaitez prolonger un Mise en œuvre totalement générique de hashset, essayez d'étendre avec } alors votre méthode d'ajout doit fonctionner avec l'objet. Boolean public Ajouter (Integer I)
{// Erreur du compilateur
retourne vrai;
}
Je ne peux pas surcharger avec une autre méthode add (objet obj)?
Non, cela gâchera votre hashset en ce qui concerne le compilateur. En effet, Set.ETT devrait obtenir un entier, mais dans votre cas où vous insérez des objets aléatoires, le compilateur n'a aucun moyen de savoir si l'ensemble contient des entiers ou non. En effet, le compilateur garantit que la méthode GET renvoiait un entier. Depuis que dans votre cas compilateur ne peut pas faire la garantie, cela ne permettra pas de ce comportement.
Vous ne pouvez pas faire cela: prolonge hashset
Le concept au travail ici s'appelle Type Erasure . Maintenant, ce serait bien si votre méthode a correctement envahi la méthode à partir de Votre FAQ sur Angelika Langer Generics
hashset Définit une méthode Ajouter (t) , et vous définissez une méthode Ajouter (objet) . En un coup d'œil, on pourrait penser que c'est d'accord; que votre méthode surcharge ajouter . Cependant, l'effacement de t est objet et les deux ont donc la même signature effacée.
hashset . Mais pour le faire, vous devriez utiliser ajouter (entier) et non ajouter (objet) . Vous ne remplissez pas correctement la méthode des parents, il est donc indiqué comme un conflit car une classe ne peut pas fournir deux méthodes avec la même signature.
ABC L'exemple suit le même raisonnement. Les deux méthodes que vous avez déclaré ont la même signature effacée afin qu'ils s'affrontent.
En plus de lecture
merci, je l'ai eu mais peu, pourquoi demander ne pas travailler dans le premier exemple
@user: Vous devriez lire tout le chemin à travers le deuxième lien de la FAQ que j'ai posté, il fait un travail approfondi d'explication de ce sujet complexe. C'est un peu beaucoup d'expliquer pleinement sur une réponse.
interface CollectionConverter<U> {
<T> List<T> toList(Collection<T> c);
void fooMethod(Class<?> c);
<E>Comparable<E> method3(E e);
Comparable<U> method4(U u);
}
class Overrider implements CollectionConverter<Integer> {
@Override
public List toList(Collection c) {
return null;
}
@Override
public void fooMethod(Class c) {
}
@Override
public Comparable method3(Object o) {
return null;
}
@Override
public Comparable method4(Integer u) {
return null;
}
}
This code works well.
In JLS: The notion of subsignature is designed to express a relationship between two methods whose signatures are not identical, but in which one may override the other. Specifically, it allows a method whose signature does not use generic types to override any generified version of that method. This is important so that library designers may freely generify methods independently of clients that define subclasses or subinterfaces of the library.