C#中的静态(编译时/严格类型)多调度支持
本文关键字:类型 支持 调度 静态 编译 | 更新日期: 2023-09-27 18:26:25
我最近发现自己在代码中反复使用相同的模式。基本上,它是访问者模式的变体,我使用它来将基类实例的引用解析为派生类实例。这种方法需要大量的样板代码。
问题:
- 如何在不编写大量访问者代码的情况下,以静态/严格类型化的方式在C#中多重调度方法
- 是否有生成此代码的工具/扩展
- 为什么C#语言中没有处理多调度的内容?我不相信我是唯一一个觉得这很烦人的人。我可能大错特错,而且这个问题根本不存在,所以我想知道你是怎么处理的
如何在不编写大量访问者代码的情况下,以静态/严格类型化的方式在C#中多重调度方法?
我不知道有什么技巧。
在用C#编写的Roslyn版本的C#编译器中,我们在具有数十或数百个成员的类型层次结构上到处使用访问者模式。我们编写了一个实用程序,它将类型的XML描述转换为类型的声明以及访问者的基类。这似乎对我们很有效。
是否有生成此代码的工具/扩展?
有;我们自己写的。这并不难。你也可以这么做。
为什么C#作为一种语言,没有任何东西可以解决多调度问题?
我们有一个可能的语言功能列表,实际上比你的手臂长。任何给定的发布,我们都有预算来做其中的两到三个,因此我们专注于获得最大可能的回报。
通过自动生成访问者模式来更容易地实现双(或多)虚拟调度,这从未使其接近列表的顶部。实际上,我们可以在语言中嵌入几十种其他可能的模式,这些模式更"划算"。如果你对流行语言进行调查,你会发现很少有语言通过静态分析支持双重或多重虚拟调度,而那些支持的语言并不太受欢迎。这是有原因的:首先,因为它实际上不是一个非常有用的功能,其次,因为当你确实需要它时,你可以通过自己实现模式或使用动态调度来实现它。
正如您所注意到的,基于模式的方法和动态调度方法都有显著的缺点。但是,尽管有缺点,但对于普通业务线的开发人员来说,如果需要的话,它们都是可行的。在评估将哪些模式嵌入到语言中时,我们倾向于那些对于普通开发人员来说很难使用基于模式的方法来实现自己的模式。访问者模式并不困难;它只是冗长。
例如:在C#2中,我们选择在语言中嵌入"序列生成器"模式。在C#3中,我们选择在语言中嵌入"带序列单元的查询理解"模式。在C#4中,我们选择在语言中嵌入"动态调度"模式。在C#5中,我们选择将"将当前延续作为委托传递"模式嵌入到该语言中。所有这些都是"物超所值"的例子——它们的实现成本很高,但它们从根本上为核心语言提供了新的编程风格。
任何版本都只有有限的工作量;在一个版本中在语言中嵌入一个模式可以防止我们在该版本中在该语言中嵌入任何其他模式,因为根本没有预算
当将"双重(或多重)虚拟调度"模式嵌入到语言中成为支出预算的最佳方式时,我们会这样做,而不是以前。因此,您应该期待漫长的等待。