Compile time safety of derived classes virtual functions?

Question

I have this code, the question is below the code:

public class MainProgram
{
    public static void Main()
    {
        List<Animal> Animals = new List<Animal>();
        Animals.Add(new Dog());
        Animals.Add(new Poodle());
        Animals.Add(new Poodle());
        Animals.Add(new Beagle());
        Animals.Add(new Cat());

        Bark[] JustTheBarks = Dog.GetBarkList(Animals);
        foreach (Bark B in JustTheBarks)
        {
            Console.WriteLine(B.ToString());
        }
    }
}

abstract class Animal
{
    public abstract Noise GetNoise();
}

class Dog : Animal
{
    public override Noise GetNoise() 
    {
        return new Bark("bark");
    }

    public static Bark[] GetBarkList(List<Animal> List)
    {
        return List
            .OfType<Dog>()
            .Select(r => r.GetNoise())
            .Cast<Bark>()
            .ToArray();
    }
}

class Beagle : Dog
{
    public override Noise GetNoise()
    {
        return new Woof("woof", 7);
    }
}

class Poodle : Dog
{
    public override Noise GetNoise()
    {
        return new Purr();
    }
}

class Cat : Animal
{
    public override Noise GetNoise()
    {
        throw new NotImplementedException();
    }
}

class Noise
{
}

class Bark : Noise
{
    protected string Text;
    public Bark(string Text)
    {
        this.Text = Text;
    }

    public override string ToString()
    {
        return $"{Text}";
    }
}


class Woof : Bark
{
    protected int Pitch;

    public Woof(string Text, int Pitch) : base(Text)
    {
        this.Pitch = Pitch;
    }
    public override string ToString()
    {
        return $"{Text}->{Pitch}";
    }
}

class Purr : Noise { }

}

In plain text, Animals and Noises, each animal returns its own type of noise, the noises correspond to the animal class, although sometimes an animal might return different Noises based on some variable (but for a dog only some form of Bark).

This code crashes of course. The Poodle returns a Purr(), and it "should" return something of type Bark. I have the abstract function GetNoise() which just returns a Noise. What I want/need is to write

class Dog
{
    public override Bark GetNoise();
}

But this is not allowed, the return type must be the same. I don't want to write a second layer of GetBark() functions in every Dog class, etc.

What I want is to re-write this such that there is no casting, and everything that is derived from Dog is forced to return a Bark in its GetNoise() function such that I can safely write:

Bark B = Dog.GetNoise();

Answer 1

The answer of Scott Chamberlain is entirely reasonable; I would add two things to it.

First, the feature you want is called "virtual method covariance". It is supported by C++, but not by C#. It has been a fairly frequently requested feature since the early days of C#, but has never been implemented because, well, frankly, it's not a great feature:

• Though type-safe in simple scenarios, it introduces new kinds of brittle base class failure in more complex, versioned scenarios
• The CLR does not support it natively, so the compiler would have to generate helper methods, which are not particularly efficient
• You can emulate the feature by implementing the helper methods yourself

If you want it, go advocate for it on the Roslyn github forum. You won't be the only one.

Second, you might consider in addition to Scott's solution to implement

public new virtual Bark GetNoise() => GetBark();

As you note, you may not fill an existing virtual method slot with any method that does not exactly match the signature and return type. But you certainly may introduce a new virtual slot with a different return type.

Answer 2

The way to do this is you seal the overload at the Dog level then make a new protected method that the children must implement.

using System;
using System.Collections.Generic;
using System.Linq;

public class MainProgram
{
    public static void Main()
    {
        List<Animal> Animals = new List<Animal>();
        Animals.Add(new Dog());
        Animals.Add(new Poodle());
        Animals.Add(new Poodle());
        Animals.Add(new Beagle());
        Animals.Add(new Cat());

        Bark[] JustTheBarks = Dog.GetBarkList(Animals);
        foreach (Bark B in JustTheBarks)
        {
            Console.WriteLine(B.ToString());
        }
    }
}

abstract class Animal
{
    public abstract Noise GetNoise();
}

class Dog : Animal
{
    public sealed override Noise GetNoise() 
    {
        return GetBark();
    }

    protected virtual Bark GetBark()
    {
        return new Bark("bark");
    }

    public static Bark[] GetBarkList(List<Animal> List)
    {
        return List
            .OfType<Dog>()
            .Select(r => r.GetBark()) //Now calls GetBark() instead of GetNoise()
            .ToArray();
    }
}

class Beagle : Dog
{
    protected override Bark GetBark()
    {
        return new Woof("woof", 7);
    }
}

class Poodle : Dog
{
    protected override Bark GetBark()
    {
        return new Purr(); //This is now a compiler error.
    }
}

class Cat : Animal
{
    public override Noise GetNoise()
    {
        throw new NotImplementedException();
    }
}

class Noise
{
}

class Bark : Noise
{
    protected string Text;
    public Bark(string Text)
    {
        this.Text = Text;
    }

    public override string ToString()
    {
        return $"{Text}";
    }
}


class Woof : Bark
{
    protected int Pitch;

    public Woof(string Text, int Pitch) : base(Text)
    {
        this.Pitch = Pitch;
    }
    public override string ToString()
    {
        return $"{Text}->{Pitch}";
    }
}

class Purr : Noise { }

Answer 3

This is a classic mis-application of OO.

Beagle and Poodle are not sub-classes of "Dog". Rather they are collectively different types of dog that share similar characteristics. They both have the same properties but the values of those properties identify groups of similar instances not sub-classes.

This is similar to the confusion of "Square" and "Rectangle" as sub-classes of shape when in fact they are both instances of a polygon. The properties they have in common (4 vertices, 4 equal internal angles of 90 degrees) do not constitute different classes of shape but different values of the properties of those shapes.

In your example the issue extends deeper into the differentiation of different characteristics of noise as sub-classes. A Purr and a Bark are both instances of a noise differentiated only by the waveform and/or the method of production.

What is missing is the nature of the noise (vocal, sub-vocal or other - e.g. insects rubbing legs/wing-cases together etc) or the purpose of the noise (warning, pleasure, anger, anxiety, pain, attracting a mate etc)

The reduction of noise making on an animal to a single method then compounds the problem.

Assuming that Cat and Dog are (more) legitimate subclasses of Animal: Cat's have the ability (a method) to Purr() but a Dog does not. A Dog has the ability to Bark() but a Cat does not. A Cat() has the ability to Meow() however and in some cases a Meow() might be considered the equivalent to a Bark() but in other cases a Hiss() might be more nearly equivalent. Yet again, when a Dog Growls() is this akin to a Cat Hiss()ing or Purr()ing (physiologically the latter, contextually the former) ?

And then there is Yelp()ing. Howl()ing. etc.

All of these are noises and independent of any particular animal type involved there is no legitimate basis for saying that if some thing is capable of making any Noise then it can only make specific sub-classes of Noise.

In short: This object model is broken. :)

Rather than try to contort the classes to fit a broken model it will serve you better in the long run to fix the model itself.

HOW to fix it is almost infinite in variety.

You might have specific methods for specific noises. You might compose those methods as members of an interface. The methods or the interfaces might be organised around the nature of the noise (IBark, IYelp, IPurr etc)

IBark.Bark()
IYelp.Yelp()

Or may have methods that are oriented around collections of behaviours (IExpressPain, IExpressHappiness):

List<EmotionalExpression> IExpressPain.ExpressionsOfPain()
List<EmotionalExpression> IExpressPain.ExpressionsOfHappiness()

Or these methods might add expressions to some specified and provided collection:

IExpressPain.ExpressIrritation(List<EmotionalExpression> expressions)

Where an EmotionalExpression might be some representation of (e.g.) Wag, Twitch, Purr, Growl etc. Where Wag and Twitch are subclasses of TailExpression and Purr and Growl are subclasses of SubVocalExpression (in turn a sub-class of AudibleExpression) etc etc. So for any particular emotionally driven behaviour an animal might express any number of different emotional expressions of different classes (physical, audible etc).

It all depends on the needs and acceptable complexities of the application.

But what I think can be said is that GetNoise() is an over-simplification and hence your difficulty.