共分散と反分散の実世界の例

Question

現実世界で共分散と反分散を使用する方法を理解するのに少し苦労しています。

これまでのところ、私が見た唯一の例は同じ古い配列の例です。

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

他の場所で使用されているのを見ることができれば、開発中に使用できる例を見ることができればうれしいです。

Answer 1

クラスPersonと、それから派生したクラスTeacherがあるとします。引数としてIEnumerable<Person>をとる操作がいくつかあります。 Schoolクラスには、IEnumerable<Teacher>を返すメソッドがあります。共分散を使用すると、IEnumerable<Person>をとるメソッドにその結果を直接使用して、派生の少ないタイプをより派生の少ない（より一般的な）タイプに置き換えることができます。直感的ではないが、共分散により、より一般的な型を使用でき、より派生した型が指定されます。

MSDNのGenericsの共分散と共分散 も参照してください。

クラス：

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

使用法：

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

Answer 2

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

完全を期すために…

// 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??

Answer 3

違いを理解するために私がまとめたものは次のとおりです

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 4

Inおよびoutキーワードは、汎用パラメーターを使用したインターフェイスおよびデリゲートのコンパイラーのキャスト規則を制御します。

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

Answer 5

継承階層を使用した簡単な例を次に示します。

単純なクラス階層がある場合：

コード内：

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

不変性（つまり、ジェネリック型パラメーター* not *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<T>_は不変なので、_IList<LifeForm>_は、パラメーター化された型TがLifeFormでなければならないコレクション（IListを実装する）のみを受け入れます。

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>_として定義）。 IEnumerableにはコレクションに変更するメソッドがありません。また、out共分散の結果、サブタイプがLifeFormのコレクションはメソッドに渡されます。

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

PrintLifeFormsは、Zebras、Giraffes、およびLifeFormのサブクラスの_IEnumerable<>_で呼び出すことができるようになりました

反分散（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<Zebra> myAction_の場合、myActionは_Action<Zebra>_の「ほとんど」になることができますが、Zebraの派生クラスはそれ以下でもかまいません。

これは最初は直感的ではないかもしれませんが（たとえば、_Action<object>_を_Action<Zebra>_を必要とするパラメーターとして渡す方法）、ステップを展開すると、呼び出された関数（PerformZebraAction）自体に気付くでしょう関数（この場合はZebraインスタンス）を関数に渡す責任があります-データは呼び出し元のコードからは送信されません。

この方法で高階関数を使用するという逆のアプローチのため、Actionが呼び出されるまでに、Zebra関数（パラメーターとして渡される）に対して呼び出されるのは、より派生したzebraActionインスタンスです。派生型。

Answer 6

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

基本的に、1つの型のEnumerableを受け取る関数がある場合は、明示的にキャストしない限り、派生型の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の動作の変化により、このような構造を使用すると、微妙で見つけにくいバグが発生する可能性があります。

Answer 7

[〜＃〜] msdn [〜＃〜] から

次のコード例は、メソッドグループの共分散と反分散のサポートを示しています

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 8

コンバーターデリゲートは、両方の概念が連携して視覚化するのに役立ちます。

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

TOutputは、共分散を表します。メソッドはより具体的なタイプを返します。

TInputはcontravarianceを表します。ここでメソッドは特定のタイプが少ないに渡されます。

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