Comment appeler base.base.method ()?

// Cannot change source code
class Base
{
    public virtual void Say()
    {
        Console.WriteLine("Called from Base.");
    }
}

// Cannot change source code
class Derived : Base
{
    public override void Say()
    {
        Console.WriteLine("Called from Derived.");
        base.Say();
    }
}

class SpecialDerived : Derived
{
    public override void Say()
    {
        Console.WriteLine("Called from Special Derived.");
        base.Say();
    }
}

class Program
{
    static void Main(string[] args)
    {
        SpecialDerived sd = new SpecialDerived();
        sd.Say();
    }
}

Le résultat est:

Appelé de Special Derived.
Appelé de dérivé. / * ce n'est pas prévu * /
Appelé depuis la base.

Comment puis-je réécrire la classe SpecialDerived afin que la méthode de la classe moyenne "Derived" ne soit pas appelée?

MISE À JOUR: La raison pour laquelle je veux hériter de Derived au lieu de Base est la classe Derived contient beaucoup d'autres implémentations. Puisque je ne peux pas faire base.base.method()ici, je suppose que la meilleure façon est de faire ce qui suit?

// Impossible de changer le code source

class Derived : Base
{
    public override void Say()
    {
        CustomSay();

        base.Say();
    }

    protected virtual void CustomSay()
    {
        Console.WriteLine("Called from Derived.");
    }
}

class SpecialDerived : Derived
{
    /*
    public override void Say()
    {
        Console.WriteLine("Called from Special Derived.");
        base.Say();
    }
    */

    protected override void CustomSay()
    {
        Console.WriteLine("Called from Special Derived.");
    }
}

Je veux juste ajouter ceci ici, car les gens reviennent encore à cette question même après plusieurs fois. Bien sûr, c'est une mauvaise pratique, mais il est toujours possible (en principe) de faire ce que l'auteur veut avec:

class SpecialDerived : Derived
{
    public override void Say()
    {
        Console.WriteLine("Called from Special Derived.");
        var ptr = typeof(Base).GetMethod("Say").MethodHandle.GetFunctionPointer();            
        var baseSay = (Action)Activator.CreateInstance(typeof(Action), this, ptr);
        baseSay();            
    }
}

Ceci est une mauvaise pratique de programmation et n'est pas autorisé en C #. C'est une mauvaise pratique de programmation car

• Les détails de la base sont les détails de mise en œuvre de la base; vous ne devriez pas compter sur eux. La classe de base fournit une abstraction par-dessus la grande base; vous devriez utiliser cette abstraction, pas construire un contournement pour l'éviter.

• Pour illustrer un exemple spécifique du point précédent: s'il est autorisé, ce modèle serait encore une autre façon de rendre le code sensible aux échecs de classe de base fragile. Supposons que Cdérive de Bqui dérive de A. Le code Cutilise base.basepour appeler une méthode de A. Ensuite, l'auteur de se Brend compte qu'il a mis trop de matériel en classe B, et une meilleure approche consiste à créer une classe intermédiaire B2qui dérive de Aet Bdérive de B2. Après ce changement, le code in Cappelle une méthode in B2, pas in A, car Cl'auteur de a fait l'hypothèse que les détails d'implémentation de B, à savoir que sa classe de base directe estA, ne changerait jamais. De nombreuses décisions de conception en C # sont d'atténuer la probabilité de divers types de défaillances de base fragile; la décision de rendre base.baseillégal empêche entièrement cette saveur particulière de ce modèle d'échec.

• Vous êtes dérivé de votre base parce que vous aimez ce qu'elle fait et que vous souhaitez la réutiliser et l'étendre. Si vous n'aimez pas ce qu'il fait et que vous voulez le contourner plutôt que de travailler avec, alors pourquoi en avez-vous dérivé en premier lieu? Dérivez vous-même de la grande base si c'est la fonctionnalité que vous souhaitez utiliser et étendre.

• La base peut nécessiter certains invariants pour des raisons de sécurité ou de cohérence sémantique qui sont maintenus par les détails de la façon dont la base utilise les méthodes de la base grand. Permettre à une classe dérivée de la base d'ignorer le code qui maintient ces invariants pourrait mettre la base dans un état incohérent et corrompu.

Vous ne pouvez pas à partir de C #. Depuis IL, cela est en fait pris en charge. Vous pouvez faire un appel non-virt à l'une de vos classes parentales ... mais ne le faites pas. :)

La réponse (dont je sais que ce n'est pas ce que vous cherchez) est:

class SpecialDerived : Base
{
    public override void Say()
    {
        Console.WriteLine("Called from Special Derived.");
        base.Say();
    }
}

La vérité est que vous n'avez qu'une interaction directe avec la classe dont vous héritez. Considérez cette classe comme une couche - fournissant autant ou aussi peu de fonctionnalités de celle-ci ou de son parent qu'il le souhaite à ses classes dérivées.

ÉDITER:

Votre modification fonctionne, mais je pense que j'utiliserais quelque chose comme ceci:

class Derived : Base
{
    protected bool _useBaseSay = false;

    public override void Say()
    {
        if(this._useBaseSay)
            base.Say();
        else
            Console.WriteLine("Called from Derived");
    }
}

Bien sûr, dans une implémentation réelle, vous pouvez faire quelque chose de plus comme ceci pour l'extensibilité et la maintenabilité:

class Derived : Base
{
    protected enum Mode
    {
        Standard,
        BaseFunctionality,
        Verbose
        //etc
    }

    protected Mode Mode
    {
        get; set;
    }

    public override void Say()
    {
        if(this.Mode == Mode.BaseFunctionality)
            base.Say();
        else
            Console.WriteLine("Called from Derived");
    }
}

Ensuite, les classes dérivées peuvent contrôler l'état de leurs parents de manière appropriée.

Pourquoi ne pas simplement convertir la classe enfant en une classe parente spécifique et appeler alors l'implémentation spécifique? Il s'agit d'une situation de cas particulier et une solution de cas particulier doit être utilisée. Vous devrez cependant utiliser le newmot - clé dans les méthodes enfants.

public class SuperBase
{
    public string Speak() { return "Blah in SuperBase"; }
}

public class Base : SuperBase
{
    public new string Speak() { return "Blah in Base"; }
}

public class Child : Base
{
    public new string Speak() { return "Blah in Child"; }
}

public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();

        Child childObj = new Child();

        Console.WriteLine(childObj.Speak());

        // casting the child to parent first and then calling Speak()
        Console.WriteLine((childObj as Base).Speak()); 

        Console.WriteLine((childObj as SuperBase).Speak());
    }
}

public class A
{
    public int i = 0;
    internal virtual void test()
    {
        Console.WriteLine("A test");
    }
}

public class B : A
{
    public new int i = 1;
    public new void test()
    {
        Console.WriteLine("B test");
    }
}

public class C : B
{
    public new int i = 2;
    public new void test()
    {
        Console.WriteLine("C test - ");
        (this as A).test(); 
    }
}

Vous pouvez également créer une fonction simple dans la classe dérivée de premier niveau, pour appeler la fonction de base principale

Mon 2c pour cela est d'implémenter la fonctionnalité dont vous avez besoin pour être appelé dans une classe de boîte à outils et de l'appeler de partout où vous en avez besoin:

// Util.cs
static class Util 
{
    static void DoSomething( FooBase foo ) {}
}

// FooBase.cs
class FooBase
{
    virtual void Do() { Util.DoSomething( this ); }
}


// FooDerived.cs
class FooDerived : FooBase
{
    override void Do() { ... }
}

// FooDerived2.cs
class FooDerived2 : FooDerived
{
    override void Do() { Util.DoSomething( this ); }
}

Cela nécessite une réflexion sur les privilèges d'accès, vous devrez peut-être ajouter des internalméthodes d' accès pour faciliter la fonctionnalité.

Dans les cas où vous n'avez pas accès à la source de la classe dérivée, mais que vous avez besoin de toute la source de la classe dérivée en plus de la méthode actuelle, je vous recommande également de créer une classe dérivée et d'appeler l'implémentation de la classe dérivée.

Voici un exemple:

//No access to the source of the following classes
public class Base
{
     public virtual void method1(){ Console.WriteLine("In Base");}
}
public class Derived : Base
{
     public override void method1(){ Console.WriteLine("In Derived");}
     public void method2(){ Console.WriteLine("Some important method in Derived");}
}

//Here should go your classes
//First do your own derived class
public class MyDerived : Base
{         
}

//Then derive from the derived class 
//and call the bass class implementation via your derived class
public class specialDerived : Derived
{
     public override void method1()
     { 
          MyDerived md = new MyDerived();
          //This is actually the base.base class implementation
          MyDerived.method1();  
     }         
}

Comme on peut le voir dans les articles précédents, on peut affirmer que si la fonctionnalité de classe doit être contournée, alors quelque chose ne va pas dans l'architecture de classe. Cela peut être vrai, mais on ne peut pas toujours restructurer ou refactoriser la structure de classe sur un grand projet mature. Les différents niveaux de gestion du changement peuvent être un problème, mais maintenir le même fonctionnement des fonctionnalités existantes après la refactorisation n'est pas toujours une tâche triviale, surtout si des contraintes de temps s'appliquent. Sur un projet mature, il peut être assez difficile d'empêcher divers tests de régression de réussir après une restructuration de code; il y a souvent des «bizarreries» obscures qui apparaissent. Nous avons eu un problème similaire dans certains cas, les fonctionnalités héritées ne devraient pas s'exécuter (ou devraient effectuer autre chose). L'approche que nous avons suivie ci-dessous, était de mettre le code de base à exclure dans une fonction virtuelle distincte. Cette fonction peut ensuite être remplacée dans la classe dérivée et la fonctionnalité exclue ou modifiée. Dans cet exemple, "Texte 2" peut être empêché de sortir dans la classe dérivée.

public class Base
{
    public virtual void Foo()
    {
        Console.WriteLine("Hello from Base");
    }
}

public class Derived : Base
{
    public override void Foo()
    {
        base.Foo();
        Console.WriteLine("Text 1");
        WriteText2Func();
        Console.WriteLine("Text 3");
    }

    protected virtual void WriteText2Func()
    {  
        Console.WriteLine("Text 2");  
    }
}

public class Special : Derived
{
    public override void WriteText2Func()
    {
        //WriteText2Func will write nothing when 
        //method Foo is called from class Special.
        //Also it can be modified to do something else.
    }
}

Il semble y avoir beaucoup de ces questions concernant l'héritage d'une méthode membre d'une classe Grand-parent, la substituant dans une seconde classe, puis l'appel à sa méthode à partir d'une classe Petit-enfant. Pourquoi ne pas simplement hériter des membres des grands-parents jusqu'aux petits-enfants?

class A
{
    private string mystring = "A";    
    public string Method1()
    {
        return mystring;
    }
}

class B : A
{
    // this inherits Method1() naturally
}

class C : B
{
    // this inherits Method1() naturally
}


string newstring = "";
A a = new A();
B b = new B();
C c = new C();
newstring = a.Method1();// returns "A"
newstring = b.Method1();// returns "A"
newstring = c.Method1();// returns "A"

Cela semble simple ... le petit-enfant hérite de la méthode des grands-parents ici. Pensez-y ... c'est ainsi que "Object" et ses membres comme ToString () sont hérités de toutes les classes en C #. Je pense que Microsoft n'a pas fait un bon travail pour expliquer l'héritage de base. L'accent est trop mis sur le polymorphisme et la mise en œuvre. Quand je fouille dans leur documentation, il n'y a pas d'exemples de cette idée très basique. :(

Si vous souhaitez accéder aux données de classe de base, vous devez utiliser le mot-clé "this" ou vous utilisez ce mot-clé comme référence pour la classe.

namespace thiskeyword
{
    class Program
    {
        static void Main(string[] args)
        {
            I i = new I();
            int res = i.m1();
            Console.WriteLine(res);
            Console.ReadLine();
        }
    }

    public class E
    {
        new public int x = 3;
    }

    public class F:E
    {
        new public int x = 5;
    }

    public class G:F
    {
        new public int x = 50;
    }

    public class H:G
    {
        new public int x = 20;
    }

    public class I:H
    {
        new public int x = 30;

        public int m1()
        {
           // (this as <classname >) will use for accessing data to base class

            int z = (this as I).x + base.x + (this as G).x + (this as F).x + (this as E).x; // base.x refer to H
            return z;
        }
    }
}