库中的C#Func <>委托

Jus*_*dro 8 .net c# compatibility delegates

来自.NET的更高版本的通用Func <>和Action <>委托是非常有吸引力的,并且已经在许多地方证明了这些可以在面向.NET 2.0的代码中轻松地重新创建,例如这里.

从针对.NET 2.0的库的角度来看,这可能是针对任何更高版本的.NET构建的应用程序所消耗的,这是如何叠加的.在库中实现这个"兼容层"绝对是一个冲突的方法(在私有和公共接口方面),还是有办法使这个工作独立于消费应用程序构建的目标框架?

如果这是一个非首发,那么它们会更好:A)定义一组具有不同名称的相同参数化代理?或者.. B)严格遵守.NET 2.0约定,并根据需要定义新的委托类型?

Ric*_*key 6

明显的事实是,Func<>Action<>是一个好主意.它们使您的代码更容易阅读,并避免了令人震惊的凌乱的样板委托声明. 这就是你想要使用它们的原因.

所以你想要使用这个非常吸引人的编程风格,它是一种标准技术,现在几乎普遍使用而不是旧方式,但你不能使用它,因为你的目标是框架的遗留版本.你该怎么办?

你有三个选择:

  1. 使用功能之前常用的编程样式
  2. 在精神上将功能添加到您自己的代码中,但名称不相互冲突
  3. 使用"真实"名称将功能添加到您自己的代码中,但在您自己的命名空间中

使用旧的编程风格放弃了我们从该功能中获得的所有好处.这是一个很大的牺牲.但也许你所有的合作开发人员都习惯了这种编程风格.

使用具有非冲突名称的功能似乎足够明智.人们将能够阅读代码并从这些功能中受益,但没有人会因为他们看起来不是他们而感到困惑.当您最终准备好升级时,您将需要修补名称.幸运的是Ctrl+R, Ctrl+R,这样做很容易.

使用与标准功能相同的功能意味着您的代码可以定位旧版本,但似乎使用较新的功能.似乎是一场双赢.但这可能会导致混淆,您必须小心您的类型不会暴露给其他未知的程序集,可能导致源代码级编译问题.因此,您必须小心并清楚地了解正在发生的事情.但它可以有效地工作.

您必须根据自己的需要选择适合您情况的方法.每个人都没有一个正确的答案,只能权衡利弊.