Exemple de covariance et de contravariance dans le monde réel

J'ai un peu de mal à comprendre comment j'utiliserais la covariance et la contravariance dans le monde réel.

Jusqu'à présent, les seuls exemples que j'ai vus sont le même ancien exemple de tableau.

object[] objectArray = new string[] { "string 1", "string 2" };

Ce serait bien de voir un exemple qui me permettrait de l'utiliser lors de mon développement si je pouvais le voir être utilisé ailleurs.

Disons que vous avez une classe Personne et une classe qui en dérive, Maître. Vous avez des opérations qui prennent un IEnumerable<Person>comme argument. Dans votre classe School, vous avez une méthode qui renvoie un fichier IEnumerable<Teacher>. La covariance vous permet d'utiliser directement ce résultat pour les méthodes qui prennent un IEnumerable<Person>, en remplaçant un type plus dérivé par un type moins dérivé (plus générique). Contravariance, contre-intuitivement, vous permet d'utiliser un type plus générique, où un type plus dérivé est spécifié.

Voir aussi Covariance et Contravariance dans les génériques sur 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);
    }
}

Utilisation :

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());

// Contravariance
interface IGobbler<in T> {
    void gobble(T t);
}

// Since a QuadrupedGobbler can gobble any four-footed
// creature, it is OK to treat it as a donkey gobbler.
IGobbler<Donkey> dg = new QuadrupedGobbler();
dg.gobble(MyDonkey());

// Covariance
interface ISpewer<out T> {
    T spew();
}

// A MouseSpewer obviously spews rodents (all mice are
// rodents), so we can treat it as a rodent spewer.
ISpewer<Rodent> rs = new MouseSpewer();
Rodent r = rs.spew();

Par souci d'exhaustivité…

// Invariance
interface IHat<T> {
    void hide(T t);
    T pull();
}

// A RabbitHat…
IHat<Rabbit> rHat = RabbitHat();

// …cannot be treated covariantly as a mammal hat…
IHat<Mammal> mHat = rHat;      // Compiler error
// …because…
mHat.hide(new Dolphin());      // Hide a dolphin in a rabbit hat??

// It also cannot be treated contravariantly as a cottontail hat…
IHat<CottonTail> cHat = rHat;  // Compiler error
// …because…
rHat.hide(new MarshRabbit());
cHat.pull();                   // Pull a marsh rabbit out of a cottontail hat??

Voici ce que j'ai mis en place pour m'aider à comprendre la différence

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

Les mots clés in et out contrôlent les règles de conversion du compilateur pour les interfaces et les délégués avec des paramètres génériques:

interface IInvariant<T> {
    // This interface can not be implicitly cast AT ALL
    // Used for non-readonly collections
    IList<T> GetList { get; }
    // Used when T is used as both argument *and* return type
    T Method(T argument);
}//interface

interface ICovariant<out T> {
    // This interface can be implicitly cast to LESS DERIVED (upcasting)
    // Used for readonly collections
    IEnumerable<T> GetList { get; }
    // Used when T is used as return type
    T Method();
}//interface

interface IContravariant<in T> {
    // This interface can be implicitly cast to MORE DERIVED (downcasting)
    // Usually means T is used as argument
    void Method(T argument);
}//interface

class Casting {

    IInvariant<Animal> invariantAnimal;
    ICovariant<Animal> covariantAnimal;
    IContravariant<Animal> contravariantAnimal;

    IInvariant<Fish> invariantFish;
    ICovariant<Fish> covariantFish;
    IContravariant<Fish> contravariantFish;

    public void Go() {

        // NOT ALLOWED invariants do *not* allow implicit casting:
        invariantAnimal = invariantFish; 
        invariantFish = invariantAnimal; // NOT ALLOWED

        // ALLOWED covariants *allow* implicit upcasting:
        covariantAnimal = covariantFish; 
        // NOT ALLOWED covariants do *not* allow implicit downcasting:
        covariantFish = covariantAnimal; 

        // NOT ALLOWED contravariants do *not* allow implicit upcasting:
        contravariantAnimal = contravariantFish; 
        // ALLOWED contravariants *allow* implicit downcasting
        contravariantFish = contravariantAnimal; 

    }//method

}//class

// .NET Framework Examples:
public interface IList<T> : ICollection<T>, IEnumerable<T>, IEnumerable { }
public interface IEnumerable<out T> : IEnumerable { }


class Delegates {

    // When T is used as both "in" (argument) and "out" (return value)
    delegate T Invariant<T>(T argument);

    // When T is used as "out" (return value) only
    delegate T Covariant<out T>();

    // When T is used as "in" (argument) only
    delegate void Contravariant<in T>(T argument);

    // Confusing
    delegate T CovariantBoth<out T>(T argument);

    // Confusing
    delegate T ContravariantBoth<in T>(T argument);

    // From .NET Framework:
    public delegate void Action<in T>(T obj);
    public delegate TResult Func<in T, out TResult>(T arg);

}//class

Voici un exemple simple utilisant une hiérarchie d'héritage.

Compte tenu de la hiérarchie de classes simple:

Et en code:

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

Invariance (c.-à-d. Paramètres de type générique * non * décorés avec des mots clés inou out)

Apparemment, une méthode comme celle-ci

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

... devrait accepter une collection hétérogène: (ce qu'elle fait)

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

Cependant, le passage d'une collection d'un type plus dérivé échoue!

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>'

Pourquoi? Parce que le paramètre générique IList<LifeForm>n'est pas covariant - IList<T>est invariant, donc IList<LifeForm>n'accepte que les collections (qui implémentent IList) où le type paramétré Tdoit être LifeForm.

Si l'implémentation de la méthode de PrintLifeFormsétait malveillante (mais a la même signature de méthode), la raison pour laquelle le compilateur empêche le passage List<Giraffe>devient évidente:

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

Puisque IListpermet l'ajout ou la suppression d'éléments, toute sous-classe de LifeFormpourrait donc être ajoutée au paramètre lifeForms, et violerait le type de toute collection de types dérivés passés à la méthode. (Ici, la méthode malveillante tenterait d'ajouter un Zebraà var myGiraffes). Heureusement, le compilateur nous protège de ce danger.

Covariance (générique avec type paramétré décoré avec out)

La covariance est largement utilisée avec les collections immuables (c'est-à-dire lorsque de nouveaux éléments ne peuvent pas être ajoutés ou supprimés d'une collection)

La solution à l'exemple ci-dessus est de s'assurer qu'un type de collection générique covariant est utilisé, par exemple IEnumerable(défini comme IEnumerable<out T>). IEnumerablen'a pas de méthode à modifier dans la collection, et en raison de la outcovariance, toute collection avec le sous-type de LifeFormpeut maintenant être passée à la méthode:

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

PrintLifeFormspeut maintenant être appelé avec Zebras, Giraffeset n'importe IEnumerable<>quelle sous-classe deLifeForm

Contravariance (générique avec type paramétré décoré avec in)

La contravariance est fréquemment utilisée lorsque les fonctions sont passées en paramètres.

Voici un exemple de fonction, qui prend un Action<Zebra>comme paramètre et l'appelle sur une instance connue d'un Zebra:

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

Comme prévu, cela fonctionne très bien:

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

Intuitivement, cela échouera:

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

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

Cependant, cela réussit

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

et même cela réussit aussi:

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

Pourquoi? Parce que Actionest défini comme Action<in T>, c'est-à-dire qu'il est contravariant, ce qui signifie que pour Action<Zebra> myAction, qui myActionpeut être au plus "a" Action<Zebra>, mais des superclasses moins dérivées de Zebrasont également acceptables.

Bien que cela puisse être non intuitif au début (par exemple, comment Action<object>passer un paramètre en tant que paramètre nécessitant Action<Zebra>?), Si vous décompressez les étapes, vous remarquerez que la fonction appelée ( PerformZebraAction) elle-même est responsable de la transmission des données (dans ce cas, une Zebrainstance ) à la fonction - les données ne proviennent pas du code appelant.

En raison de l'approche inversée consistant à utiliser des fonctions d'ordre supérieur de cette manière, au moment où l ' Actionest invoqué, c'est l' Zebrainstance la plus dérivée qui est invoquée contre la zebraActionfonction (passée en paramètre), bien que la fonction elle-même utilise un type moins dérivé.

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>'
}

Fondamentalement, chaque fois que vous aviez une fonction qui prend un Enumerable d'un type, vous ne pouviez pas passer un Enumerable d'un type dérivé sans le cast explicitement.

Juste pour vous avertir d'un piège:

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");
}

C'est du code horrible de toute façon, mais il existe et le changement de comportement en C # 4 peut introduire des bogues subtils et difficiles à trouver si vous utilisez une construction comme celle-ci.

Depuis MSDN

L'exemple de code suivant montre la prise en charge de la covariance et de la contravariance pour les groupes de méthodes

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;
}

Contravariance

Dans le monde réel, vous pouvez toujours utiliser un abri pour animaux au lieu d'un abri pour lapins car chaque fois qu'un refuge pour animaux héberge un lapin, c'est un animal. Cependant, si vous utilisez un refuge pour lapins au lieu d'un refuge pour animaux, son personnel peut être mangé par un tigre.

Dans le code, cela signifie que si vous avez un , IShelter<Animal> animalsvous pouvez simplement écrire IShelter<Rabbit> rabbits = animals si vous promettez et l' utilisation Tdans la IShelter<T>seule en tant que paramètres de la méthode comme ceci:

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;
    }
}

et remplacer un élément par un élément plus générique, c'est-à-dire réduire la variance ou introduire une contre- variance.

Covariance

Dans le monde réel, vous pouvez toujours utiliser un fournisseur de lapins au lieu d'un fournisseur d'animaux car chaque fois qu'un fournisseur de lapins vous donne un lapin, c'est un animal. Cependant, si vous utilisez un fournisseur d'animaux au lieu d'un fournisseur de lapins, vous pouvez être mangé par un tigre.

Dans le code, cela signifie que si vous avez un, ISupply<Rabbit> rabbitsvous pouvez simplement écrire ISupply<Animal> animals = rabbits si vous promettez et utiliser Tdans la ISupply<T>méthode only as des valeurs de retour comme suit:

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;
    }
}

et remplacer un élément par un élément plus dérivé, c'est-à-dire augmenter la variance ou introduire la co- variance.

Dans l'ensemble, il ne s'agit que d'une promesse vérifiable lors de la compilation de votre part selon laquelle vous traiteriez un type générique d'une certaine manière pour garder le type en sécurité et ne pas faire manger personne.

Vous voudrez peut-être lire ceci pour revenir en arrière.

Le délégué convertisseur m'aide à visualiser les deux concepts fonctionnant ensemble:

delegate TOutput Converter<in TInput, out TOutput>(TInput input);

TOutputreprésente la covariance où une méthode renvoie un type plus spécifique .

TInputreprésente une contravariance où une méthode reçoit un type moins spécifique .

public class Dog { public string Name { get; set; } }
public class Poodle : Dog { public void DoBackflip(){ System.Console.WriteLine("2nd smartest breed - woof!"); } }

public static Poodle ConvertDogToPoodle(Dog dog)
{
    return new Poodle() { Name = dog.Name };
}

List<Dog> dogs = new List<Dog>() { new Dog { Name = "Truffles" }, new Dog { Name = "Fuzzball" } };
List<Poodle> poodles = dogs.ConvertAll(new Converter<Dog, Poodle>(ConvertDogToPoodle));
poodles[0].DoBackflip();