Covariance and contravariance real world example

Question

I\'m having a little trouble understanding how I would use covariance and contravariance in the real world.

So far, the only examples I\'ve seen have been the same o

Answer 1

From MSDN

The following code example shows covariance and contravariance support for method groups

static object GetObject() { return null; }
static void SetObject(object obj) { }

static string GetString() { return ""; }
static void SetString(string str) { }

static void Test()
{
    // Covariance. A delegate specifies a return type as object, 
    // but you can assign a method that returns a string.
    Func<object> del = GetString;

    // Contravariance. A delegate specifies a parameter type as string, 
    // but you can assign a method that takes an object.
    Action<string> del2 = SetObject;
}

Answer 2

Here's what I put together to help me understand the difference

public interface ICovariant<out T> { }
public interface IContravariant<in T> { }

public class Covariant<T> : ICovariant<T> { }
public class Contravariant<T> : IContravariant<T> { }

public class Fruit { }
public class Apple : Fruit { }

public class TheInsAndOuts
{
    public void Covariance()
    {
        ICovariant<Fruit> fruit = new Covariant<Fruit>();
        ICovariant<Apple> apple = new Covariant<Apple>();

        Covariant(fruit);
        Covariant(apple); //apple is being upcasted to fruit, without the out keyword this will not compile
    }

    public void Contravariance()
    {
        IContravariant<Fruit> fruit = new Contravariant<Fruit>();
        IContravariant<Apple> apple = new Contravariant<Apple>();

        Contravariant(fruit); //fruit is being downcasted to apple, without the in keyword this will not compile
        Contravariant(apple);
    }

    public void Covariant(ICovariant<Fruit> fruit) { }

    public void Contravariant(IContravariant<Apple> apple) { }
}

tldr

ICovariant<Fruit> apple = new Covariant<Apple>(); //because it's covariant
IContravariant<Apple> fruit = new Contravariant<Fruit>(); //because it's contravariant

Answer 3

class A {}
class B : A {}

public void SomeFunction()
{
    var someListOfB = new List<B>();
    someListOfB.Add(new B());
    someListOfB.Add(new B());
    someListOfB.Add(new B());
    SomeFunctionThatTakesA(someListOfB);
}

public void SomeFunctionThatTakesA(IEnumerable<A> input)
{
    // Before C# 4, you couldn't pass in List<B>:
    // cannot convert from
    // 'System.Collections.Generic.List<ConsoleApplication1.B>' to
    // 'System.Collections.Generic.IEnumerable<ConsoleApplication1.A>'
}

Basically whenever you had a function that takes an Enumerable of one type, you couldn't pass in an Enumerable of a derived type without explicitly casting it.

Just to warn you about a trap though:

var ListOfB = new List<B>();
if(ListOfB is IEnumerable<A>)
{
    // In C# 4, this branch will
    // execute...
    Console.Write("It is A");
}
else if (ListOfB is IEnumerable<B>)
{
    // ...but in C# 3 and earlier,
    // this one will execute instead.
    Console.Write("It is B");
}

That is horrible code anyway, but it does exist and the changing behavior in C# 4 might introduce subtle and hard to find bugs if you use a construct like this.

Answer 4

Here's a simple example using an inheritance hierarchy.

Given the simple class hierarchy:

And in code:

public abstract class LifeForm  { }
public abstract class Animal : LifeForm { }
public class Giraffe : Animal { }
public class Zebra : Animal { }

Invariance (i.e. generic type parameters *not* decorated with in or out keywords)

Seemingly, a method such as this

public static void PrintLifeForms(IList<LifeForm> lifeForms)
{
    foreach (var lifeForm in lifeForms)
    {
        Console.WriteLine(lifeForm.GetType().ToString());
    }
}

... should accept a heterogeneous collection: (which it does)

var myAnimals = new List<LifeForm>
{
    new Giraffe(),
    new Zebra()
};
PrintLifeForms(myAnimals); // Giraffe, Zebra

However, passing a collection of a more derived type fails!

var myGiraffes = new List<Giraffe>
{
    new Giraffe(), // "Jerry"
    new Giraffe() // "Melman"
};
PrintLifeForms(myGiraffes); // Compile Error!

cannot convert from 'System.Collections.Generic.List<Giraffe>' to 'System.Collections.Generic.IList<LifeForm>'

Why? Because the generic parameter IList<LifeForm> is not covariant - IList<T> is invariant, so IList<LifeForm> only accepts collections (which implement IList) where the parameterized type T must be LifeForm.

If the method implementation of PrintLifeForms was malicious (but has same method signature), the reason why the compiler prevents passing List<Giraffe> becomes obvious:

 public static void PrintLifeForms(IList<LifeForm> lifeForms)
 {
     lifeForms.Add(new Zebra());
 }

Since IList permits adding or removal of elements, any subclass of LifeForm could thus be added to the parameter lifeForms, and would violate the type of any collection of derived types passed to the method. (Here, the malicious method would attempt to add a Zebra to var myGiraffes). Fortunately, the compiler protects us from this danger.

Covariance (Generic with parameterized type decorated with out)

Covariance is widely used with immutable collections (i.e. where new elements cannot be added or removed from a collection)

The solution to the example above is to ensure that a covariant generic collection type is used, e.g. IEnumerable (defined as IEnumerable<out T>). IEnumerable has no methods to change to the collection, and as a result of the out covariance, any collection with subtype of LifeForm may now be passed to the method:

public static void PrintLifeForms(IEnumerable<LifeForm> lifeForms)
{
    foreach (var lifeForm in lifeForms)
    {
        Console.WriteLine(lifeForm.GetType().ToString());
    }
}

PrintLifeForms can now be called with Zebras, Giraffes and any IEnumerable<> of any subclass of LifeForm

Contravariance (Generic with parameterized type decorated with in)

Contravariance is frequently used when functions are passed as parameters.

Here's an example of a function, which takes an Action<Zebra> as a parameter, and invokes it on a known instance of a Zebra:

public void PerformZebraAction(Action<Zebra> zebraAction)
{
    var zebra = new Zebra();
    zebraAction(zebra);
}

As expected, this works just fine:

var myAction = new Action<Zebra>(z => Console.WriteLine("I'm a zebra"));
PerformZebraAction(myAction); // I'm a zebra

Intuitively, this will fail:

var myAction = new Action<Giraffe>(g => Console.WriteLine("I'm a giraffe"));
PerformZebraAction(myAction); 

cannot convert from 'System.Action<Giraffe>' to 'System.Action<Zebra>'

However, this succeeds

var myAction = new Action<Animal>(a => Console.WriteLine("I'm an animal"));
PerformZebraAction(myAction); // I'm an animal

and even this also succeeds:

var myAction = new Action<object>(a => Console.WriteLine("I'm an amoeba"));
PerformZebraAction(myAction); // I'm an amoeba

Why? Because Action is defined as Action<in T>, i.e. it is contravariant, meaning that for Action<Zebra> myAction, that myAction can be at "most" a Action<Zebra>, but less derived superclasses of Zebra are also acceptable.

Although this may be non-intuitive at first (e.g. how can an Action<object> be passed as a parameter requiring Action<Zebra> ?), if you unpack the steps, you will note that the called function (PerformZebraAction) itself is responsible for passing data (in this case a Zebra instance) to the function - the data doesn't come from the calling code.

Because of the inverted approach of using higher order functions in this manner, by the time the Action is invoked, it is the more derived Zebra instance which is invoked against the zebraAction function (passed as a parameter), although the function itself uses a less derived type.

Answer 5

Contravariance

In the real world, you can always use a shelter for animals instead of a shelter for rabbits because every time an animal shelter hosts a rabbit it is an animal. However, if you use a rabbit shelter instead of an animal shelter its staff can get eaten by a tiger.

In code, this means that if you have an IShelter<Animal> animals you can simply write IShelter<Rabbit> rabbits = animals if you promise and use T in the IShelter<T> only as method parameters like so:

public class Contravariance
{
    public class Animal { }
    public class Rabbit : Animal { }

    public interface IShelter<in T>
    {
        void Host(T thing);
    }

    public void NoCompileErrors()
    {
        IShelter<Animal> animals = null;
        IShelter<Rabbit> rabbits = null;

        rabbits = animals;
    }
}

and replace an item with a more generic one, i.e. reduce the variance or introduce contravariance.

Covariance

In the real world, you can always use a supplier of rabbits instead of a supplier of animals because every time a rabbit supplier gives you a rabbit it is an animal. However, if you use an animal supplier instead of a rabbit supplier you can get eaten by a tiger.

In code, this means that if you have an ISupply<Rabbit> rabbits you can simply write ISupply<Animal> animals = rabbits if you promise and use T in the ISupply<T> only as method return values like so:

public class Covariance
{
    public class Animal { }
    public class Rabbit : Animal { }

    public interface ISupply<out T>
    {
        T Get();
    }

    public void NoCompileErrors()
    {
        ISupply<Animal> animals = null;
        ISupply<Rabbit> rabbits = null;

        animals = rabbits;
    }
}

and replace an item with a more derived one, i.e. increase the variance or introduce covariance.

All in all, this is just a compile-time checkable promise from you that you would treat a generic type in a certain fashion to keep the type safety and not get anyone eaten.

You might want to give this a read to double-wrap your head around this.

Answer 6

Let's say you have a class Person and a class that derives from it, Teacher. You have some operations that take an IEnumerable<Person> as the argument. In your School class you have a method that returns an IEnumerable<Teacher>. Covariance allows you to directly use that result for the methods that take an IEnumerable<Person>, substituting a more derived type for a less derived (more generic) type. Contravariance, counter-intuitively, allows you to use a more generic type, where a more derived type is specified.

See also Covariance and Contravariance in Generics on MSDN.

Classes:

public class Person 
{
     public string Name { get; set; }
} 

public class Teacher : Person { } 

public class MailingList
{
    public void Add(IEnumerable<out Person> people) { ... }
}

public class School
{
    public IEnumerable<Teacher> GetTeachers() { ... }
}

public class PersonNameComparer : IComparer<Person>
{
    public int Compare(Person a, Person b) 
    { 
        if (a == null) return b == null ? 0 : -1;
        return b == null ? 1 : Compare(a,b);
    }

    private int Compare(string a, string b)
    {
        if (a == null) return b == null ? 0 : -1;
        return b == null ? 1 : a.CompareTo(b);
    }
}

Usage:

var teachers = school.GetTeachers();
var mailingList = new MailingList();

// Add() is covariant, we can use a more derived type
mailingList.Add(teachers);

// the Set<T> constructor uses a contravariant interface, IComparer<in T>,
// we can use a more generic type than required.
// See https://msdn.microsoft.com/en-us/library/8ehhxeaf.aspx for declaration syntax
var teacherSet = new SortedSet<Teachers>(teachers, new PersonNameComparer());