How did you work around covariant return types? Before the language allowed it?

Question

I need some help with design logic, illustrated by an example. My question below.

public class ChangeSet { }
public class NodeChangeSet : ChangeSet { }

public abstract class Base
{
   protected abstract Action<ChangeSet> Do { get; }
}

public class Node:Base
{
   private void doIt(NodeChangeSet change) { }

   protected override Action<NodeChangeSet> Do => (s)=> doIt(s); //Error

}

My intent is that Node should only ever care about handling a NodeChangeSet and should never need to understand or be aware that an abstracted ChangeSet exists. Node should be the only class that cares about the Type of NodeChangeSet, i.e. it should be properly abstracted in the base class and elsewhere; nobody should know or care about the NodeChangeSet type.

P.S. I am aware this might be possible in C# 9.0, so my question is: what workaround would you have implemented prior to C# 9.0?

Answer 1

C# (and any language with similar type requirements) does not allow to make input of an overridden implementation narrower (to exclude some types that base class supports as valid parameters) and output wider (to return values that no longer compatible with return of the base class method) - this will break inheritance expectations - LSP.

Your code wants to limit types your derived class take as argument (as "in" parameter of action delegate) to just subset of what base class supports - caller of that method can't guarantee that only subset of types will be used there. In particular someClassDerivedFromBase.Do(new ChangeSet()); should work for all derived types - the way you setting up the Node type would have no way to handle parameter of ChangeSet or any other type that is not derived from NodeChangeSet and the missing part of the code would need to be somehow created. While some imaginary compiler could come up with solution to throw something like "NotSupportedException" in this particular case inventing desired behavior is not something compilers usually do.

So your options:

• respect the base class method signature - override the method as-is (Action<ChangeSet>) and do necessary type checking at run-time
• change base class to actually take real type of the change and use that in the abstract method (note that this will make Base<SomeChangeSet> and Base<OtherChangeSet> to no longer be related via inheritance and hence can't be used interchangeably): Base<TChangeSet> where TChangeSet:ChangeSet

The code that could work with variance is either narrowing return type ("out") in the derived type:

protected abstract Func<ChangeSet, BaseResult> Do { get; }

// in derived you can return narrower results as it will be always BaseResult
protected override Func<ChangeSet, DerivedResult> Do { get;}

or widening argument types ("in"):

protected abstract Action<DerivedChangeSet> Do { get; }

// in derived accept wider set of types for the action:
protected override Action<BaseChangeSet> Do { get; }