Литье T интерфейса & lt; T & gt; к интерфейсу & lt; baseT & gt; [Дубликат]

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

В принципе, всякий раз, когда у вас есть функция, которая принимает перечислимый тип одного типа, вы не можете передавать в Enumerable производного типа без явно его литья.

Просто, чтобы предупредить вас о ловушка хотя:

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 # 4 может привести к тонким и трудным для поиска ошибкам, если вы используете такую ​​конструкцию.

Вот простой пример использования иерархии наследования.

Учитывая простую иерархию классов:

                        Giraffe
                      /
LifeForm <- Animal <- 
                      \
                        Zebra

В коде:

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

Инвариантность ( Общий с параметризованным типом, украшенным ни in, ни out)

По-видимому, такой метод, как этот

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

..., должен принимать гетерогенный набор: (который это делает)

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

Однако передача набора из более производного типа не выполняется!

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

Почему? Поскольку общий параметр IList<LifeForm> не является ковариантным - IList<LifeForm> является инвариантным и принимает только коллекции (которые реализуют IList), где параметризованный тип T должен быть LifeForm.

Если я злонамеренно изменяю реализацию метода PrintLifeForms (но оставляю одну и ту же сигнатуру метода), причина, по которой компилятор предотвращает передачу List<Giraffe>, становится очевидным:

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

Поскольку IList позволяет добавлять или удалять элементы, любой подкласс LifeForm может быть добавлен к параметру lifeForms и будет нарушать тип любой коллекции производных типов, переданных методу. (В этом случае вредоносный метод попытается добавить Zebra в var myGiraffes). К счастью, компилятор защищает нас от этой опасности.

Ковариация (общий с параметризованным типом, украшенный out)

Ковариация широко используется с неизменяемыми коллекциями (то есть, когда новые элементы не могут быть добавлено или удалено из коллекции)

Решение вышеприведенного примера заключается в том, чтобы использовать ковариантный общий тип, например IEnumerable (определяется как IEnumerable<out T>). Это предотвращает изменение коллекции, и в результате теперь может быть передана любая коллекция с подтипом LifeForm:

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

PrintLifeForms() теперь можно вызвать с помощью Zebras, Giraffes и любой IEnumerable<> любого подкласса LifeForm

Контравариантность (общий с параметризованным типом, украшенным in)

Контравариантность часто используется, когда функции передаются как Параметры.

Вот пример функции, которая принимает параметр Action<Zebra> в качестве параметра и вызывает его на известном экземпляре Zebra:

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

Как и ожидалось, это прекрасно работает:

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

Интуитивно это не удастся:

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

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

Однако, это преуспевает

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

, и даже это также удается:

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

Почему? Поскольку Action определяется как Action<in T>, то есть contravariant.

Хотя это может быть сначала неинтуитивным (например, как можно передать Action<object> как параметр, требующий Action<Zebra> ]?), если вы распакуете этапы, вы заметите, что сама вызываемая функция (PerformZebraAction) отвечает за передачу данных (в данном случае экземпляра Zebra) в функцию - данные не поступают из вызывающий код.

Из-за инвертированного подхода к использованию функций более высокого порядка таким образом, к тому времени, когда вызывается Action, это более производный экземпляр объекта, который вызывается против функции zebraAction (передается как параметр), который сам использует менее производный тип.

Делегатор конвертера помогает мне визуализировать обе совместно работающие концепции:

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

TOutput представляет ковариацию, в которой метод возвращает более конкретный тип .

TInput представляет собой контравариантность, когда метод передается менее конкретным типом .

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