标签：null log ble cbo oid 问题 seo png width
逆变（contravariant）与协变（covariant）是C#4新增的概念，许多书籍和博客都有讲解，我觉得都没有把它们讲清楚，搞明白了它们，可以更准确地去定义泛型委托和接口，这里我尝试画图详细解析逆变与协变。
我们都知道.Net里或者说在OO的世界里，可以安全地把子类的引用赋给父类引用，例如：
|
1
2
3
|
//父类 = 子类string str = "string";object obj = str;//变了 |
而C#里又有泛型的概念，泛型是对类型系统的进一步抽象，比上面简单的类型高级，把上面的变化体现在泛型的参数上就是我们所说的逆变与协变的概念。通过在泛型参数上使用in或out关键字，可以得到逆变或协变的能力。下面是一些对比的例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
//泛型委托：public delegate T MyFuncA<T>();//不支持逆变与协变public delegate T MyFuncB<out T>();//支持协变MyFuncA<object> funcAObject = null;MyFuncA<string> funcAString = null;MyFuncB<object> funcBObject = null;MyFuncB<string> funcBString = null;MyFuncB<int> funcBInt = null;funcAObject = funcAString;//编译失败，MyFuncA不支持逆变与协变funcBObject = funcBString;//变了，协变funcBObject = funcBInt;//编译失败，值类型不参与协变或逆变//泛型接口public interface IFlyA<T> { }//不支持逆变与协变public interface IFlyB<out T> { }//支持协变IFlyA<object> flyAObject = null;IFlyA<string> flyAString = null;IFlyB<object> flyBObject = null;IFlyB<string> flyBString = null;IFlyB<int> flyBInt = null;flyAObject = flyAString;//编译失败，IFlyA不支持逆变与协变flyBObject = flyBString;//变了，协变flyBObject = flyBInt;//编译失败，值类型不参与协变或逆变//数组：string[] strings = new string[] { "string" };object[] objects = strings; |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
public delegate void MyActionA<T>(T param);//不支持逆变与协变public delegate void MyActionB<in T>(T param);//支持逆变public interface IPlayA<T> { }//不支持逆变与协变public interface IPlayB<in T> { }//支持逆变MyActionA<object> actionAObject = null;MyActionA<string> actionAString = null;MyActionB<object> actionBObject = null;MyActionB<string> actionBString = null;actionAString = actionAObject;//MyActionA不支持逆变与协变,编译失败actionBString = actionBObject;//变了，逆变IPlayA<object> playAObject = null;IPlayA<string> playAString = null;IPlayB<object> playBObject = null;IPlayB<string> playBString = null;playAString = playAObject;//IPlayA不支持逆变与协变,编译失败playBString = playBObject;//变了，逆变 |
来到这里我们看到有的能变，有的不能变，要知道以下几点：
那么in/out是什么意思呢？为什么加了它们就有了“变”的能力，是不是我们定义泛型委托或者接口都应该添加它们呢？
原来，在泛型参数上添加了in关键字作为泛型修饰符的话，那么那个泛型参数就只能用作方法的输入参数，或者只写属性的参数，不能作为方法返回值等，总之就是只能是“入”，不能出。out关键字反之。
当尝试编译下面这个把in泛型参数用作方法返回值的泛型接口时：
|
1
2
3
4
|
public interface IPlayB<in T>{ T Test();} |
出现了如下编译错误：
错误 1 方差无效: 类型参数“T”必须为“CovarianceAndContravariance.IPlayB<T>.Test()”上有效的 协变式。“T”为 逆变。
到这里，我们大致知道了逆变与协变的相关概念，那么为什么把泛型参数限制为in或者out就可以“变”呢？下面尝试画图解释原理。
我们先来看看不支持逆变与协变的泛型，把子类赋给父类，再执行父类方法的具体流程，对于这样一个简单的例子的Test方法：
|
1
2
3
4
5
6
7
8
9
10
|
public interface Base<T>{ T Test(T param);}public class Sub<T> : Base<T>{ public T Test(T param) { return default(T); }}Base<string> b = new Sub<string>();b.Test(""); |
它实际的流程是这样的：
即调用父类的方法，其实实际是调用子类的方法。可以看到，这个方法能够安全的调用，需要两个条件：1.变式（父）的方法参数能安全转为原式（子）的 参数；2.原式（子）的返回值能安全的转为变式的返回值。不幸的是参数的流向跟返回值的流向是相反的，所以对于既是in，又是out的泛型参数来说，肯定 是行不通的，其中一个方向必然不能安全转换的。例如，对上面的例子，我们尝试“变”：
|
1
2
3
4
|
Base<object> BaseObject = null;Base<string> BaseString = null;BaseObject = BaseString;//编译失败BaseObject.Test(""); |
这里的“实际流程”如下，可以看到，参数那里是object是不能安全转换为string，所以编译失败：
看到这里如果都明白的话，我们不难得到逆变与协变的”实际流程图”（记住，它们是有in/out限制的）:
可以看到，从”实际流程图”来看，逆变根本没有“逆”，都离不开只能安全地把子类的引用赋给父类引用这个根本。
来到这里应该基本理解逆变与协变了，不过装配脑袋的这篇文章有个更高级的问题，原文也有解答，这里我用上面画图的方式去理解它。
问题的提出，你知道那个正确吗？
|
1
2
3
4
5
6
7
8
9
10
11
|
public interface IBar<in T> { }//应该是inpublic interface IFoo<in T>{ void Test(IBar<T> bar);}//还是outpublic interface IFoo<out T>{ void Test(IBar<T> bar);} |
答案是，如果是in的话，会编译失败，out才正确（当然不要泛型修饰符也能通过编译，但IFoo就没有协变能力了）。这里的意思就是说，一个有协 变（逆变）能力的泛型（IBar），作为另一个泛型（IFoo）的参数时，影响到了它（IFoo）的泛型的定义。乍一看以为是in的其中一个陷阱是T是在 Test方法的参数里的，所以以为是in。但这里Test的参数根本不是T，而是IBar<T>。
我们画个图来理解它。既然out可以通过，那么它的“协变流程图”应该如下：
图跟前面那些大致一样，但理解它要跟问题相反（上面问题是先定义好IBar，再去定义IFoo）。1.我们定义好一个有协变能力的IFoo,这是前 提。2.可以推出，上面的流程是成立的。3.这个流程重点是参数流向，要使整个流程成立，就必须使IBar<string> = IBar<object>成立，这不就是逆变吗？整个结论就是，有协变能力的IFoo要求它的泛型参数（IBar）有逆变能力。其实根据上面的箭头也可以理解，因为原式和变式的变向跟参数的变向是相反的，导致了它们要有相反的能力，这就是装配脑袋文章说的：方法参数的协变-反变互换原则。根据这个原理，也很容易得出，如果Test方法的返回值是IBar<T>，而不是参数，那么就要求IBar<T>要有协变能力，因为返回值的箭头与原式和变式的变向的箭头是同向的。
The End！
转自：http://www.cnblogs.com/lemontea/archive/2013/02/17/2915065.html
标签：null log ble cbo oid 问题 seo png width
原文地址：http://www.cnblogs.com/ChineseMoonGod/p/6926019.html
