如果您发现自己在苦苦维持强类型化数据结构的同时，又冀望于最大化运行时灵活性，那么您大概会愿意考虑反射，以及它如何改善您的软件。在本专栏中，我将探讨 Microsoft .NET Framework 中的 System.Reflection 命名空间，以及它如何为您的开发体验提供助益。我将从一些简单的示例开始，最后将讲述如何处理现实世界中的序列化情形。在此过程中，我会展示反射和 CodeDom 如何配合工作，以有效处理运行时数据。
在深入探究 System.Reflection 之前，我想先讨论一下一般的反射编程。首先，反射可定义为由一个编程系统提供的任何功能，此功能使程序员可以在无需提前了解其标识或正式结构的情况下检查和操作代码实体。这部分内容很多，我将逐一展开说明。
首先，反射提供了什么呢?您能用它做些什么呢?我倾向于将典型的以反射为中心的任务分为两类：检查和操作。检查需要分析对象和类型，以收集有关其定义和行为的结构化信息。除了一些基本规定之外，通常这是在事先不了解它们的情况下进行的。(例如，在 .NET Framework 中，任何东西都继承自 System.Object，并且一个对象类型的引用通常是反射的一般起点。)
操作利用通过检查收集到的信息动态地调用代码，创建已发现类型的新实例，或者甚至可以轻松地动态重新结构化类型和对象。需要指出的一个要点是，对于大多数系统，在运行时操作类型和对象，较之在源代码中静态地进行同等操作，会导致性能降低。由于反射的动态特性，因此这是个必要的取舍，不过有很多技巧和最佳做法可以优化反射的性能(有关优化使用反射的更多深入信息，请参见 msdn.microsoft.com/msdnmag/issues/05/07/Reflection)。
那么，什么是反射的目标呢?程序员实际检查和操作什么呢?在我对反射的定义中，我用了“代码实体”这个新术语，以强调一个事实：从程序员的角度来说，反射技术有时会使传统对象和类型之间的界限变得模糊。例如，一个典型的以反射为中心的任务可能是：
从对象 O 的句柄开始，并使用反射获得其相关定义(类型 T)的句柄。
检查类型 T，获得它的方法 M 的句柄。
调用另一个对象 O’(同样是类型 T)的方法 M。
请注意，我在从一个实例穿梭到它的底层类型，从这一类型到一个方法，之后又使用此方法的句柄在另一个实例上调用它 — 显然这是在源代码中使用传统的 C# 编程技术无法实现的。在下文中探讨 .NET Framework 的 System.Reflection 之后，我会再次通过一个具体的例子来解释这一情形。
某些编程语言本身可以通过语法提供反射，而另一些平台和框架(如 .NET Framework)则将其作为系统库。不管以何种方式提供反射，在给定情形下使用反射技术的可能性相当复杂。编程系统提供反射的能力取决于诸多因素：程序员很好地利用了编程语言的功能表达了他的概念吗?编译器是否在输出中嵌入足够的结构化信息(元数据)，以方便日后的解读?有没有一个运行时子系统或主机解释器来消化这些元数据?平台库是否以对程序员有用的方式，展示此解释结果?
