提升组件灵活性：CLR反射与运行时智能

165 浏览量更新于2024-08-30 收藏 149KB PDF 举报

"本文档深入探讨了CLR（Common Language Runtime）中的反射机制，特别是System.Reflection命名空间。作者针对软件工程中的特定问题提出了思考：在追求组件化设计时，如果库间共享过多类型信息导致灵活性受限，或者需要在运行时动态适应对象模型变化，如何在保持强类型化的数据存储同时提升灵活性。反射提供了一种解决方案，允许开发者在不预先了解对象标识或结构的情况下，检查和操作代码。反射的核心任务主要分为两方面：检查和操作。检查涉及分析对象和类型，获取关于其定义和行为的结构化信息，即使在未知情况下也能进行。例如，.NET Framework中的所有类型都基于System.Object，这构成了反射操作的基本起点。操作则利用检查结果动态调用代码，创建新实例，甚至改变类型和对象的结构。然而，由于反射在运行时执行动态操作可能会影响性能，程序员需要权衡并采用优化策略来提升效率。MSDN上有关于如何有效使用反射以提高性能的深入指南。反射的目标在于提供一种在编程时能够灵活处理和操作代码实体的能力，而不受类型或结构的硬编码限制。这使得库的使用者能够以编程方式定义自己的类型，并在运行时以智能化的方式处理对象，尤其是在处理序列化和反序列化场景时，反射与CodeDOM（代码对象模型）的结合尤为重要。通过一系列实例和应用场景，作者将逐步揭示System.Reflection的细节，帮助读者理解如何在实际开发中有效地利用这一强大的工具，提升软件的灵活性和可维护性。"

CLR完全介绍完全介绍-反射之反思反射之反思

火龙果软件工程技术中心

清晰的组件化目标是否因在库间共享过多类型信息而落空？或许您需要高效的强类型化数据存储，但如果每次对象模型发展后

都需要更新您的数据库架构，那会耗费很大成本，所以您更愿意在运行时推断出其类型架构吗？您需要交付能接受任意用户对

象的组件，并以某种智能化的方式处理它们吗？您希望库的调方者能以编程方式向您说明它们的类型吗？

如果您发现自己在苦苦维持强类型化数据结构的同时，又冀望于最大化运行时灵活性，那么您大概会愿意考虑反射，以及它如

何改善您的软件。在本专栏中，我将探讨 Microsoft

.NET Framework 中的 System.Reflection 命名空间，以及它如何为您的

开发体验提供助益。我将从一些简单的示例开始，最后将讲述如何处理现实世界中的序列化情形。在此过程中，我会展示反射

和 CodeDom 如何配合工作，以有效处理运行时数据。

在深入探究 System.Reflection 之前，我想先讨论一下一般的反射编程。首先，反射可定义为由一个编程系统提供的任何功

能，此功能使程序员可以在无需提前了解其标识或正式结构的情况下检查和操作代码实体。这部分内容很多，我将逐一展开说

明。

首先，反射提供了什么呢？您能用它做些什么呢？我倾向于将典型的以反射为中心的任务分为两类：检查和操作。检查需要分

析对象和类型，以收集有关其定义和行为的结构化信息。除了一些基本规定之外，通常这是在事先不了解它们的情况下进行

的。（例如，在 .NET Framework 中，任何东西都继承自 System.Object，并且一个对象类型的引用通常是反射的一般起点。

）

操作利用通过检查收集到的信息动态地调用代码，创建已发现类型的新实例，或者甚至可以轻松地动态重新结构化类型和对

象。需要指出的一个要点是，对于大多数系统，在运行时操作类型和对象，较之在源代码中静态地进行同等操作，会导致性能

降低。由于反射的动态特性，因此这是个必要的取舍，不过有很多技巧和最佳做法可以优化反射的性能（有关优化使用反射的

更多深入信息，请参见 msdn.microsoft.com/msdnmag/issues/05/07/Reflection）。

那么，什么是反射的目标呢？程序员实际检查和操作什么呢？在我对反射的定义中，我用了“代码实体”这个新术语，以强调一

个事实：从程序员的角度来说，反射技术有时会使传统对象和类型之间的界限变得模糊。例如，一个典型的以反射为中心的任

务可能是：

1. 从对象 O 的句柄开始，并使用反射获得其相关定义（类型 T）的句柄。

2. 检查类型 T，获得它的方法 M 的句柄。

3. 调用另一个对象 O’（同样是类型 T）的方法 M。

请注意，我在从一个实例穿梭到它的底层类型，从这一类型到一个方法，之后又使用此方法的句柄在另一个实例上调用它 —

显然这是在源代码中使用传统的 C# 编程技术无法实现的。在下文中探讨 .NET Framework 的 System.Reflection 之后，我会

再次通过一个具体的例子来解释这一情形。

某些编程语言本身可以通过语法提供反射，而另一些平台和框架（如 .NET Framework）则将其作为系统库。不管以何种方式

提供反射，在给定情形下使用反射技术的可能性相当复杂。编程系统提供反射的能力取决于诸多因素：程序员很好地利用了编

程语言的功能表达了他的概念吗？编译器是否在输出中嵌入足够的结构化信息（元数据），以方便日后的解读？有没有一个运

行时子系统或主机解释器来消化这些元数据？平台库是否以对程序员有用的方式，展示此解释结果？

如果您头脑中想象的是一个复杂的、面向对象类型的系统，但在代码中却表现为简单的、C 语言风格的函数，而且没有正式的

数据结构，那么显然您的程序不可能动态地推断出，某变量 v1 的指针指向某种类型 T 的对象实例。因为毕竟类型 T 是您头脑

中的概念，它从未在您的编程语句中明确地出现。但如果您使用一种更为灵活的面向对象语言（如 C#）来表达程序的抽象结

构，并直接引入类型 T 的概念，那么编译器就会把您的想法转换成某种日后可以通过合适的逻辑来理解的形式，就象公共语

言运行时 (CLR) 或某种动态语言解释器所提供的一样。

反射完全是动态、运行时的技术吗？简单的说，不是这样。整个开发和执行周期中，很多时候反射对开发人员都可用且有用。

一些编程语言通过独立编译器实现，这些编译器将高级代码直接转换成机器能够识别的指令。输出文件只包括编译过的输入，

并且运行时没有用于接受不透明对象并动态分析其定义的支持逻辑。这正是许多传统 C 编译器的情形。因为在目标可执行文

件中几乎没有支持逻辑，因此您无法完成太多动态反射，然而编译器会不时提供静态反射 — 例如，普遍运用的 typeof 运算符

允许程序员在编译时检查类型标识。

另一种完全不同的情况是，解释性编程语言总是通过主进程获得执行（脚本语言通常属于此类）。由于程序的完整定义是可用

的（作为输入源代码），并跟完整的语言实现结合在一起（作为解释器本身），因此所有支持自我分析所需的技术都到位了。

这种动态语言频繁地提供全面反射功能，以及一组用于动态分析和操作程序的丰富工具。

.NET Framework CLR 和它的承载语言如 C# 属于中间形态。编译器用来把源代码转换成 IL 和元数据，后者与源代码相比虽

属于较低级别或者较低“逻辑性”，但仍然保留了很多抽象结构和类型信息。一旦 CLR 启动和承载了此程序，基类库 (BCL) 的

System.Reflection 库便可以使用此信息，并返回关于对象类型、类型成员、成员签名等的信息。此外，它也可以支持调用，

包括后期绑定调用。

.NET 中的反射中的反射

要在用 .NET Framework 编程时利用反射，您可以使用 System.Reflection 命名空间。此命名空间提供封装了很多运行时概念

的类，例如程序集、模块、类型、方法、构造函数、字段和属性。图 1 中的表显示，System.Reflection 中的类如何与概念上

下载后可阅读完整内容，剩余7页未读，立即下载

weixin_38713099

粉丝: 4
资源: 905

提升组件灵活性：CLR反射与运行时智能

CLR 完全介绍--托管代码与非托管代码之间的封送处理

clr-via-csharp-4th-edition-code（clr-via-c#第四版源代码）

logging.pattern.console=%clr(%d{yyyy-MM-dd HH:mm:ss}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(-){faint} %clr([%14.14t]){faint} %clr(%-40.40logger.%13.13M){cyan} %clr(%3.3L) %clr(:){faint} %msg%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}

clr-namespace是什么意思

var(--clr)

74ls175功能表和引脚图

clr中心对数变换逆变换

LTE各信道 ACLR 标准

在Linux系统下，XP-CLR分析详细步骤

利用74LS163的同步清零功能构成六进制计数器 画出状态图、写出归零逻辑表达式、画连线图

最新资源

利用74LS163的同步清零功能构成六进制计数器画出状态图、写出归零逻辑表达式、画连线图