nouveau mot dans les interfaces en c #

voix
3
using System;

namespace random

{

    interface IHelper
    {
        void HelpMeNow();
    }
    public class Base : IHelper
    {
        public void HelpMeNow()
        {
            Console.WriteLine(Base.HelpMeNow());
        }
    }
    public class Derived : Base
    {
        public new void HelpMeNow()            ///this line
        {
            Console.WriteLine(Derived.HelpMeNow());
        }
    }
    class Test
    {
        public static void Main()
        {
            Derived der = new Derived();
            der.HelpMeNow();
            IHelper helper = (IHelper)der;
            helper.HelpMeNow();
            Console.ReadLine();
        }
    }
}

le nouveau mot-clé dans la ligne de commentaire est un peu déroutant pour moi. Il jsut signifie qu'il annule la mise en œuvre de la méthode dans la classe de base. Pourquoi ne pas utiliser mot-clé override?

Créé 27/08/2009 à 01:01
source utilisateur
Dans d'autres langues...                            


3 réponses

voix
9

Voir cet article sur MSDN: Quand utiliser Override et nouveaux mots - clés

Créé 27/08/2009 à 01:03
source utilisateur

voix
0

Il est primordial , il pas vraiment, il est shadowing il. Étant donné une référence à un Derivedobjet, Baseest HelpMeNowfonction ne sera pas accessible 1 , et derivedObject.HelpMeNow()appellera Derived« la mise en œuvre de l' art.

Ce n'est pas la même chose que la suppression d' un fonction virtuelle, qui HelpMeNown'est pas. Si un Derivedobjet est stocké dans une référence à un Baseou à une IHelper, puis Base's HelpMeNow()sera appelée, et Derivedest mise en œuvre sera inaccessible.

Derived derivedReference = new Derived();
Base    baseReference    = derivedReference;
IHelper helperReference  = derivedReference;

derivedReference.HelpMeNow(); // outputs "Derived.HelpMeNow()"
baseReference.HelpMeNow();    // outputs "Base.HelpMeNow()"
helperReference.HelpMeNow();  // outputs "Base.HelpMeNow()"

Bien sûr, si ce qui précède n'est pas le comportement souhaité, et il est généralement pas, il y a deux possibilités. Si vous contrôlez Base, il suffit de changer HelpMeNow()de virtuel, et la remplacer au Derivedlieu de shadowing il. Si vous ne contrôlez pas Base, vous pouvez au moins fixer à mi - chemin, par réimplémentant IHelper, comme suit:

class Derived : Base, IHelper{
    public new void HelpMeNow(){Console.WriteLine("Derived.HelpMeNow()");}

    void IHelper.HelpMeNow(){HelpMeNow();}
}

Cette version Derivedutilise ce qu'on appelle la mise en œuvre d'interface explicite , ce qui vous permet de satisfaire le contrat de mise en œuvre d' une interface sans ajouter la mise en œuvre à l' interface publique de votre classe. Dans cet exemple, nous avons déjà une mise en œuvre dans l' Derivedinterface publique » qui a hérité de Base, donc nous devons mettre en œuvre explicitement IHelperde le changer 2 . Dans cet exemple, nous venons de transmettrons la mise en œuvre de IHelper.HelpMeNownotre interface publique, qui est l'ombre de Base« s.

Donc , avec ce changement, un appel à baseReference.HelpMeNow()sorties encore « Base.HelpMeNow () », mais un appel à helperReference.HelpMeNow()va maintenant sortie « Derived.HelpMeNow () ». Pas aussi bon que le changement Base« de la mise en œuvre au virtuel, mais aussi bon que nous allons obtenir si nous ne contrôlons pas Base.

1 Exception: il est accessible à partir de méthodes de Derived, mais seulement quand qualifié avec base., comme base.HelpMeNow().
2 Notez que nous avons également déclarer IHelpercomme interface les outils de classe, même si nous héritons cette déclaration de Base.

Créé 27/08/2009 à 01:33
source utilisateur

voix
0

En général, si l'interface IBase implémente un membre DoSomething et IDerived hérite / met en œuvre Ibase, il attend à ce que IDerived.DoSomething sera synonyme de IBase.DoSomething. En général, ce qui est utile, car il permet d'économiser de la classe implémenteurs d'avoir à fournir des implémentations redondantes. Il y a, cependant, certains cas où une interface dérivée doit mettre en œuvre un élément qui a le même nom en tant que membre dans l'interface de base, mais qui devra être mis en œuvre séparément. Les situations les plus courantes sont (1) la méthode dérivée aura un autre type de retour du type de base, ou (2) l'interface de base (s) met en œuvre un ReadOnly et / ou WriteOnly propriété (s) avec un certain et dérivé le type devrait mettre en œuvre une propriété en lecture-écriture. Pour une raison quelconque, si l'interface IReadableFoo fournit une propriété en lecture seule Foo, IWritableFoo fournit une propriété en écriture seule Foo et IMutableFoo d'interface hérite simplement à la fois, le compilateur ne saura pas si une référence à Foo se réfère à IReadableFoo.Foo ou IWritableFoo.Foo. Même si seulement IReadableFoo.Foo peut être lu, et seulement IWritableFoo.Foo peut être écrit, ni vb.net, ni C # ne peut résoudre la surcharge sauf si on met en oeuvre une nouvelle propriété en lecture-écriture Foo qui gère à la fois.

Créé 24/07/2011 à 20:42
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more