C#小测试（二）：嵌套子类带来的困惑

这里有个很有意思的题目，先别运行程序，猜猜它会输出什么？

public class A<T>
{
    public class B : A<int>
    {
        public void M()
        {
            Console.WriteLine(typeof(T).ToString());
        }
        public class C : B { }
    }
}

class Program
{
    static void Main(string[] args)
    {
        A<string>.B.C c = new A<string>.B.C();
        c.M();
    }
}

这里的T是int、string还是其它的什么？还是程序压根儿就不能通过编译？

...

...

...

答案是System.Int32，你猜对了吗？很可能这跟你的期望值并不一致。我们来看看它背后的玄妙之处。

有人认为c.M方法输出Int32，因为B的声明B : A<int>告诉B，T将一直是int。这好像是有道理的，却不是真正的原因。我们先不管C，执行这一行代码(new A<string>.B()).M()，它会输出：String。B是A<int>的子类并不意味着B中的T总是int。

问题的根本在于声明class C : B会产生不明确的内容：即是class C : A<T>.B 还是class C : A<int>.B？我们得首先搞清楚这个问题。

先看继承和嵌套类的区别：

public class X
{
    public void M() { }
}

public class Y
{
    public void N() { }
    public class Z : X { }
}

...

(new Y.Z()).M(); // 合法，M是继承自基类的方法
(new Y.Z()).N(); // 不合法，外部类的成员不是内部类的方法

在我们的测试题中，我们调用了A<string>.B.C类的方法M，它本质上则调用了基类的M方法。如果基类是A<T>.B，那么应调用A<T>.B.M，即输出T的当前值：String；如果基类是A<int>.B，那么应调用A<int>.B.M，即总是输出：Int32。

而程序的结果告诉我们C#选择了后者。是不是有些不可思议？

也许程序中的泛型扰乱我们的直觉。那就看一个不使用泛型的例子：

public class D
{
    public class E { }
}

public class F
{
    public class E { }
    public class G
    {
        public E e; // 很明显这里是 F.E
    }
}

public class H : D
{
    public E e; // 很明显这里是 D.E
}

OK，目前为止，一切都是合法的，而且也没什么异议。当我们通过类型名称来引用类型时，类型可以来自于基类（H.e），也可以来自于外部类（G.e）。但是如果这两种情况同时出现会如何呢？

public class J
{
    public class E { }
    public class K : D
    {
        public E e; // 是J.E 还是D.E?
    }
}

这种情况是合法的吗？答案是肯定的。此时C#认为基类要优先于外部类。这也合乎常理，派生类与基类的关系是“is-a”，内部类与外部类的关系是“包含于”，前者要比后者更为紧密。

还可以这么理解：从基类继承下来的成员都属于“当前的作用域”，因此从“外部的作用域”获得的成员的优先级要低一些。

一般地，对于一个类型S，在其上下文中对一个名称进行解析的算法是：

• S的类型参数（type parameter）
• S可以访问的内部类
• S的基类中可以访问的内部类（访问基类的顺序是由近及远）
• S的外部类

现在回到开始的问题。我们看看在解析C的基类的时候发生了什么。我们调用的是B.M()，所以问题可以转化为找到正确的B。首先C没有类型参数，也没有内部类。

A<T>.B的基类是A<int>，而外部类则是A<T>，两者都有一个名称为B的内部类。选哪一个呢？根据上面的算法，基类优先，即A<int>.B。

这个过程实在是非常的绕，虽然跟着文章得出了结论，还是有些模糊。。。

参考：

An Inheritance Puzzle, Part One

An Inheritance Puzzle, Part Two