Force a parent class method to call overridden methods instead of child overrides

Question

public class C1 {
    public virtual void A() { Console.WriteLine("Good"); }
    public void B() { A(); } // <-- wrong A when when called in child classes :(
}
public class C2 : C1 {
    public override void A() { B(); }
}

Is there anything I can do in C2 such that when C2.A() calls B() the next call is to C1.A() instead of C2.A() which leads to infinite recursion?

Answer 1

Wouldn't this simply be enough? Move the implementation of A into a separate, private, method in the base class, then call that instead from the base class?

public class C1 {
    private void AImplementation() { Console.WriteLine("Good"); }
    public virtual void A() { AImplementation(); }
    public void B() { AImplementation(); }
}
public class C2 : C1 {
    public override void A() { B(); }
}

Answer 2

Knowing that you're in full on hack mode helps. This hack probably works in more scenarios than the other suggestion. But it is omgway slower. This implementation tries to be as generic as possible. But, you could probably just grab the frame at the appropriate hardcoded index & check/compare declaring types if you only wanted to solve this particular example.

public class C1 {
    public virtual void A() { Console.WriteLine("Good"); }
    public void B() { A(); }
}
public class C2 : C1 {
    public override void A()
    {
        var method = new System.Diagnostics.StackTrace()
                    .GetFrames().Skip(1).Select(f => f.GetMethod())
                    .FirstOrDefault(m => m.Name == nameof(A) && m.DeclaringType == typeof(C2));
        if (method == null) B();
        else base.A();
    }
}

Or, like I said you could just check if

var method = new System.Diagnostics.StackTrace().GetFrame(2).GetMethod();
if (method.Name != nameof(A)) B();
else base.A();

As everyone else has said though, this is a terrible solution that you'd fix with better design if you could.

Answer 3

A helpful person on IRC provided this hacky non-thread-safe solution:

public class C1 {
    public virtual void A() { Console.WriteLine("Good"); }
    public void B() { A(); }
}
public class C2 : C1 {
    bool _aOnCallStack = false;
    public override void A() { 
        if (!_aOnCallStack) {
            _aOnCallStack = true;
            B(); 
        }
        else {
            base.A();
            _aOnCallStack = false;
        }
    }
}

Answer 4

I had to rename your classes and methods - the As, Bs and Cs were driving me nuts.

NOTE: This is a redo, after your comment that the base class had to be left alone. I think this answers your question. It's hacky, but I think it should work:

public class Base {
    public virtual void TheVirtualFunction() {
        Console.WriteLine($"Base Class Implemenation of Virtual Function from type {GetType().Name}");
    }
    public void NonVirtualFuction() {
        Console.WriteLine($"The non-Virtual Function - Calling Vitual function now from type {GetType().Name}");
        TheVirtualFunction();
    }
}

public class Sub : Base
{
    private bool _isCallingAgain = false;
    public override void TheVirtualFunction()
    {
        Console.WriteLine($"Sub Class Implemenation of Virtual Function from type {GetType().Name}");
        if (_isCallingAgain)
        {
            Console.WriteLine($"Skipping because v-func called twice from type {GetType().Name}");
            return;
        }
        _isCallingAgain = true;
        Console.WriteLine($"This pass through the virtual function does something (from type {GetType().Name})");
        NonVirtualFuction();
        _isCallingAgain = false;
    }
}

Then, in my Main function, I have code that looks like:

static void Main(string[] args) {
    var theBase = new Base();
    Console.WriteLine("Calling Base Class Non Virtual function");
    theBase.NonVirtualFuction();

    Console.WriteLine("\r\nCalling Base Class Virtual function directly");
    theBase.TheVirtualFunction();

    var theSub = new Sub();
    Console.WriteLine("\r\nCalling Non-Virtual Function (implemented in the base class) using sub-class reference");
    theSub.NonVirtualFuction();

    Console.WriteLine("\r\nCalling Sub Class Virtual function directly");
    theSub.TheVirtualFunction();

    Console.ReadLine();
}

The result of all that is this spew to the console:

Calling Base Class Non Virtual function
The non-Virtual Function - Calling Vitual function now from type Base
Base Class Implemenation of Virtual Function from type Base

Calling Base Class Virtual function directly
Base Class Implemenation of Virtual Function from type Base

Calling Non-Virtual Function (implemented in the base class) using sub-class reference
The non-Virtual Function - Calling Vitual function now from type Sub
Sub Class Implemenation of Virtual Function from type Sub
This pass through the virtual function does something (from type Sub)
The non-Virtual Function - Calling Vitual function now from type Sub
Sub Class Implemenation of Virtual Function from type Sub
Skipping because v-func called twice from type Sub

Calling Sub Class Virtual function directly
Sub Class Implemenation of Virtual Function from type Sub
This pass through the virtual function does something (from type Sub)
The non-Virtual Function - Calling Vitual function now from type Sub
Sub Class Implemenation of Virtual Function from type Sub
Skipping because v-func called twice from type Sub

Note that it calls the sub-class virtual function twice, but a guard bit keeps it from doing anything on the second time through. This is pretty much what you came up with, but I did it independently.

The guard bit (_isCallingAgain) is a private instance member variable. It is necessarily accessed on a single thread of execution (the path of execution comes into the Sub's v-func, goes up into the Base's non-virtual function, and then comes back into the Sub's v-func again). There's no need to guard it with a lock or another else (other than making sure it is private).

I think this (or a variation on this) is your only choice. A non-reentrancy guard like this is a pretty common pattern (it was very common back in the day when I did MFC and Win32 Windows UI programming).