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


本文转自一个程序员的自省博客园博客,原文链接:http://www.cnblogs.com/anderslly/archive/2008/08/04/an-inheritance-puzzle.html,如需转载请自行联系原作者。

目录
相关文章
|
3月前
|
开发框架 .NET C#
C#|.net core 基础 - 删除字符串最后一个字符的七大类N种实现方式
【10月更文挑战第9天】在 C#/.NET Core 中,有多种方法可以删除字符串的最后一个字符,包括使用 `Substring` 方法、`Remove` 方法、`ToCharArray` 与 `Array.Copy`、`StringBuilder`、正则表达式、循环遍历字符数组以及使用 LINQ 的 `SkipLast` 方法。
|
4月前
|
存储 C# 索引
C# 一分钟浅谈:数组与集合类的基本操作
【9月更文挑战第1天】本文详细介绍了C#中数组和集合类的基本操作,包括创建、访问、遍历及常见问题的解决方法。数组适用于固定长度的数据存储,而集合类如`List<T>`则提供了动态扩展的能力。文章通过示例代码展示了如何处理索引越界、数组长度不可变及集合容量不足等问题,并提供了解决方案。掌握这些基础知识可使程序更加高效和清晰。
98 2
|
15天前
|
开发框架 .NET Java
C#集合数据去重的5种方式及其性能对比测试分析
C#集合数据去重的5种方式及其性能对比测试分析
32 11
|
17天前
|
开发框架 .NET Java
C#集合数据去重的5种方式及其性能对比测试分析
C#集合数据去重的5种方式及其性能对比测试分析
42 10
|
3月前
|
测试技术 C# 数据库
C# 单元测试框架 NUnit 一分钟浅谈
【10月更文挑战第17天】单元测试是软件开发中重要的质量保证手段,NUnit 是一个广泛使用的 .NET 单元测试框架。本文从基础到进阶介绍了 NUnit 的使用方法,包括安装、基本用法、参数化测试、异步测试等,并探讨了常见问题和易错点,旨在帮助开发者有效利用单元测试提高代码质量和开发效率。
185 64
|
1月前
|
算法 Java 测试技术
Benchmark.NET:让 C# 测试程序性能变得既酷又简单
Benchmark.NET是一款专为 .NET 平台设计的性能基准测试框架,它可以帮助你测量代码的执行时间、内存使用情况等性能指标。它就像是你代码的 "健身教练",帮助你找到瓶颈,优化性能,让你的应用跑得更快、更稳!希望这个小教程能让你在追求高性能的路上越走越远,享受编程带来的无限乐趣!
111 13
|
2月前
|
缓存 监控 数据挖掘
C# 一分钟浅谈:性能测试与压力测试
【10月更文挑战第20天】本文介绍了性能测试和压力测试的基础概念、目的、方法及常见问题与解决策略。性能测试关注系统在正常条件下的响应时间和资源利用率,而压力测试则在超出正常条件的情况下测试系统的极限和潜在瓶颈。文章通过具体的C#代码示例,详细探讨了忽视预热阶段、不合理测试数据和缺乏详细监控等常见问题及其解决方案,并提供了如何避免这些问题的建议。
67 7
|
3月前
|
测试技术 开发者
vertx的学习总结6之动态代理类和测试
本文是Vert.x学习系列的第六部分,介绍了如何使用动态代理在事件总线上公开服务,以及如何进行Vert.x组件的异步测试,包括动态代理的创建和使用,以及JUnit 5和Vert.x测试工具的结合使用。
37 3
vertx的学习总结6之动态代理类和测试
|
3月前
|
Java 程序员 测试技术
Java|让 JUnit4 测试类自动注入 logger 和被测 Service
本文介绍如何通过自定义 IDEA 的 JUnit4 Test Class 模板,实现生成测试类时自动注入 logger 和被测 Service。
46 5
|
2月前
|
Kubernetes 测试技术 持续交付
C# 一分钟浅谈:集成测试与系统测试
【10月更文挑战第19天】本文详细介绍了集成测试和系统测试的概念、目的及其在软件开发中的重要性。通过分析常见问题和易错点,结合代码示例,探讨了如何通过代码规范、自动化测试和持续集成等方法提高测试效果,确保软件质量和可靠性。
140 1