Remplacement d'une méthode avec des Paramètres Génériques en Java?

J'ai une Classe abstraite Monitor.java qui est sous-classé par une Classe EmailMonitor.java.

La méthode:

public abstract List<? extends MonitorAccount> performMonitor(List<? extends MonitorAccount> accounts)

est défini dans Monitor.java et doit être remplacée dans les EmailMonitor.java.

J'ai actuellement la méthode substituée dans EmailMonitor.java comme suit:

@Override
public List<EmailAccount> performMonitor(List<EmailAccount> emailAccounts) {
    //...unrelated logic
    return emailAccounts;
}

Cependant, ce qui produit l'erreur de compilation:

Name clash: The method performMonitor(List<EmailAccount>) of type EmailMonitor has the same erasure as performMonitor(Lis<? extends MonitorAccount> emailAccounts) of type Monitor but does not override it

EmailAccount est une sous-classe de MonitorAccount, (dans mon esprit au moins) remplaçant dans cette façon tout à fait logique. Vu que le compilateur n'est pas heureux avec ma logique, Comment dois-je m'y prendre correctement tout en gardant mon moment de la compilation des vérifications pour s'assurer que tous les appels à EmailMonitor.performMonitor() recevoir des Listes de EmailAccount plutôt que d'un autre type de MonitorAccount?

InformationsquelleAutor Robert Ngetich | 2008-10-27
  1. 34

    Non, il n'est pas primordial correctement. Primordial signifie que vous devriez être en mesure de faire face à toutes les entrées valides pour la classe de base. Demander ce qui se passerait si un client fait:

    Monitor x = new EmailMonitor();
List<NonEmailAccount> nonEmailAccounts = ...;
x.performMonitor(nonEmailAccounts);

    Il n'y a rien là qui donne une erreur de compilation, compte tenu de votre description, mais c'est clairement faux.

    Il me semble Monitor doit être générique dans le type de compte il vous permet de contrôler, de sorte que votre EmailMonitor devrait s'étendre Monitor<EmailAccount>. Donc:

    public abtract class Monitor<T extends MonitorAccount>
{
    ...
    public abstract List<? extends T> performMonitor(
        List<? extends T> accounts);
}

public class EmailMonitor extends Monitor<EmailAccount>
{
    @Override
    public abstract List<? extends EmailAccount> performMonitor(
        List<? extends EmailAccount> accounts)
    {
        //Code goes here
    }
}

    Vous pourriez vouloir penser attentivement à l'génériques dans la performMonitor appel si - quelle est la valeur de retour censé signifier?

    • Vous dites " Liste<? s'étend EmailAccount>'. Maintenant, je ne peux pas passer EmailAccount grâce à tous; Était-ce une faute de frappe?. Je voulais vérifier que EmailMonitor reçoit toujours une liste de EmailAccount et renvoie toujours une liste de EmailAccount qui peut être utilisé sans la dynamique de la coulée. de poster ma solution maintenant 🙂
    InformationsquelleAutor Jon Skeet
  2. 9

    Voici ma propre solution. Je suppose que c'est la même chose Jon Skeet a été d'essayer d'obtenir au... sans la faute de frappe (voir mon commentaire en réponse à sa réponse).

    le Monitor.java classe:

    public abstract class Monitor <T extends MonitorAccount> {
  ...
  public abstract List<T> performMonitor(List<T> accounts);
  ..
}

    EmailMonitor.java

    public class EmailMonitor extends Monitor<EmailAccount> {
  ...
  public List<EmailAccount> performMonitor(List<EmailAccount> emailAccounts) {
    ..//logic...logic...logic
    return emailAccounts;
  }
  ...
}

    Dans cette configuration, EmailMonitor.performMonitor() sera toujours vérifier au moment de la compilation qu'il reçoit une liste de EmailAccount plutôt que d'autres types de FTPAccount, DBAccount, etc... C'est beaucoup plus propre que l'autre alternative, ce qui aurait été la réception/l'envoi d'une crue de la liste et puis d'avoir à forcer le type susceptibles de provoquer une exécution de conversion de types d'exceptions.

    • EmailMonitor ne s'étend pas MonitorAccount
    InformationsquelleAutor Robert Ngetich