un résumé de classe hérite d'une autre classe abstraite problème

J'ai un héritage schéma comme ci-dessous:

public abstract class BaseAttachment
{
    public abstract string GetName();
}

public abstract class BaseFileAttachment:BaseAttachment
{
    public abstract string GetName();
}

public class ExchangeFileAttachment:BaseFileAttachment
{
    string name;
    public override string GetName()
    {
        return name;
    }
}

En gros, je voulez l'appeler la méthode GetName() de la ExchangeFileAttachment classe; Toutefois, la déclaration ci-dessus est faux. Tout, est très appréciée. Grâce

  • Est-ce votre intention de fournir une nouvelle GetName méthode sur BaseFileAttachment qui cache BaseAttachment.GetName? Si non, il suffit d'omettre l'redeclaration.
  • Pourquoi est - ExchangeFileAttachment déclaré abstract?
  • "Toutefois, la déclaration ci-dessus est fausse", Vous devriez vraiment fournir plus de détails dans vos questions. N'est-il pas compiler? N'est-il pas de faire ce que vous désirez? Si oui, quelles sont les erreurs ou les comportements indésirables?
  • Pour ce que ça vaut au moins compile bien, donc il n'y a que. Je pense que ce serait assez génial d'avoir plus de détails si, pour sûr.
  • Il est encore possible de son problème à l'être que son projet n'est pas de la compilation, ce qui nous aurait dit que son problème, c'est dans le code qui n'est pas posté, ou qu'il a changé quelque chose lors de la publication du code.
  • Re, oups! En fait il y a une erreur de compilation dans le code tel qu'il est. Les hérité résumé membre cacher entraîne le compilateur à l'échec de la construction. Je pensais que c'était juste mon Resharper configuration de repérage il y a comme une erreur jusqu'à ce que j'ai vérifié tout à l'heure.
  • j'ai oublié de vérifier. ExchangeFileAttachment classe n'est pas abstrait. Merci pour cette remarque.
  • double possible de Pourquoi une classe abstraite de mettre en œuvre une méthode abstraite d'une classe de base abstraite?. Si le titre est trompeur, la question est la même..

InformationsquelleAutor stoney78us | 2012-11-27
  1. 19

    Les deux problèmes que je vois, c'est que votre finale ExchangeFileAttachment classe est déclarée abstract, de sorte que vous ne serez jamais en mesure de l'instancier. Sauf si vous avez un autre niveau de l'héritage, vous ne nous montrent pas, en l'appelant, il ne sera pas possible - il n'y a pas moyen d'y accéder. L'autre problème est que BaseFileAttachment a une propriété qui est de cacher les GetName() dans BaseAttachment. Dans la structure que vous nous montrant, il est superflu et peut être omis. Ainsi, le "corrigé" code ressemblerait plus à:

    public abstract class BaseAttachment
{
    public abstract string GetName();
}

public abstract class BaseFileAttachment : BaseAttachment
{
}

public class ExchangeFileAttachment : BaseFileAttachment
{
    string name;
    public override string GetName()
    {
        return name;
    }
}

    J'ai mis corrigé entre guillemets parce que ce cas d'utilisation n'est toujours pas faire une tonne de sens, donc je suis en espérant que vous pouvez donner plus d'informations, ou de ce fait beaucoup plus de sens sur votre fin.

    • Cet exemple de code aidé ma réponse un tout autre question!
    InformationsquelleAutor tmesser
  2. 11

    Il suffit de retirer le redeclaration de BaseFileAttachment:

    public abstract class BaseFileAttachment : BaseAttachment
{
}

    BaseFileAttachment déjà hérite de l'abstrait GetName déclaration de BaseAttachment. Si vous voulez vraiment parler de nouveau dans BaseFileAttachment, utilisez le override mot-clé:

    public abstract class BaseFileAttachment : BaseAttachment
{
    public override abstract string GetName(); //that's fine as well
}
    • cela fonctionne! merci
    InformationsquelleAutor Heinzi