.net - 泛型 hell 或在 .NET 中进行程序集级别类型参数化(程序集范围泛型)需要什么

Question

不确定这个问题到底是关于什么的。

问题来了。假设，我正在开发一个框架，该框架将被打包到一个没有可用源代码的程序集中并作为产品发布。从一开始，框架的开发就考虑到了可扩展性，我的意思是一些目标域细节/数据/类将由引用框架的最终用户/程序集定义。启用它的方法之一是在框架中使用泛型，以便稍后定义所有内容。但是一旦将泛型引入单个类，所有依赖/引用类和方法都必须使用所有确切的约束重新声明它。传递一个泛型没什么大不了的，但是当你不得不处理时，事情很快就会失控，比如 8 个，这一点也不罕见。在框架中的每个小类中，您必须放置几行刚刚重新声明的类型参数，这些参数在所有类中都是相同的。似乎一个快速而肮脏的解决方案只是拥有某种类似 c++ 的宏，它将相同的通用声明添加到所有(大多数)类。但是C#没有宏，所以你必须自己动手。这是我们提出一个问题的地方:如何将这些参数从括号中取出并在程序集(项目)级别声明一次？这样您就不必编写“public class Entity* * { ... }”，因为 TField 已定义，无论何时您看到它，都意味着该类隐含地知道它使用与汇编级别相同的声明。通过链接此类通用程序集，开发人员必须在能够使用它之前提供所有类型参数，或者如果某些参数仍未绑定(bind)，则重新声明它们以供以后使用。

问题:

• 您遇到过这样的情况吗？
• 您认为拥有此功能可能会有帮助吗？
• 如果是这样，您目前在没有人的情况下如何相处？
• 对于那些正在使用 C# 的人:你们有什么机会将它添加到某个新版本的 C# 中？

谢谢!

更新:

我不想说太多细节，但如你所愿。很难做出一个很好的说明性例子，所以让我分享一下现有情况。我正在研究一个文本处理框架，其中我有一个核心库，可以标记文本并具有所有可能的模式来匹配它。它不知道的是如何处理名词和动词等词性。幸运的是，还有另一个组件可以做到这一点。现在的目标是利用来自另一个库的词性知识来扩展核心库中的模式。我这样做的方法是我向名为“CustomPattern”的核心库添加了一个特殊模式，该模式由一个可以用任何东西替换的任意类参数化。在我们的例子中，它是 PartOfSpeech 枚举。查看 https://gist.github.com/2651642 处的代码段.

这里的问题是，如何避免在核心库中使用 TDetails 泛型，同时又能够使用附加了任意数据的自定义模式？

这里唯一的要求是我们必须严格按照现在的方式输入代码。

Answer 1

have you ever found yourself in a situation like this?

是的。

do you think that having this feature might be helpful?

我认为能够跨类定义/共享通用约束会很有用，尽管我对任何“全局”事物都持谨慎态度，因为存在滥用的可能性。

if so, how do you currently get along without one?

我发现我有过度使用泛型的倾向——尽管它们很有用——它们并不是每项任务的最佳选择。

最近我承担了使我的框架库之一对 WCF 友好的任务。到我完成时，几乎每个通用接口(interface)都被重新设计，或者创建了一个非通用的等效接口(interface)。这是因为需要简化我的界面，以便更好地作为操作契约(Contract)和数据契约(Contract)工作，但当我完成时，我得出的结论是设计更清晰、更直观，我几乎没有放弃。

如果您评估您的设计，您可能会发现可以通过要求输入参数从基类型或接口(interface)继承来替换严格约束的通用接口(interface)。

例如，如果类型参数 TField1 必须是 Foo 类型的可实例化类，为什么不直接更改接口(interface)以要求 Foo(或者更可能是其子类)？

public void Act<TField> where TField : Foo, new() { }

成为

public void Act( Foo f ) { } 

或

public void Act( IFoo f ){ }

如果类被设计为作用于一个输入对象，通常它必须有一些关于该对象的成员和能力的知识。

例如，List<T>( T obj )不需要对输入值做太多其他存储，但是 TransferMoneyFromAccount<TAccount>( TAccount obj )可能确实需要对输入数据做非常具体的事情。它可能会更改为 TransferMoneyFromAccount( IAccount obj )

对于您的库的使用者，我认为接口(interface)比泛型更优雅地执行契约的概念。

for those who is working on c#: what is a chance that you guys will add this to some new version of c#?

来自一位从事 C# 工作的人 (Eric Lippert):

I'm often asked why the compiler does not implement this feature or that feature, and of course the answer is always the same: because no one implemented it. Features start off as unimplemented and only become implemented when people spend effort implementing them: no effort, no feature.

取自:http://blogs.msdn.com/b/ericlippert/archive/2012/03/09/why-not-automatically-infer-constraints.aspx (巧合的是一篇关于泛型类型约束的文章)