C# 扩展方法架构问题答案

【问题标题】：C# Extension Methods Architecture QuestionC# 扩展方法架构问题
【发布时间】：2010-10-12 22:29:03
【问题描述】：

Marc Gravell 的回答非常完美，它解决了我的问题。但它给了我一些思考......

如果扩展方法必须放在静态类上，并且方法本身必须是静态的，为什么不能创建静态扩展方法？

我了解标记为“this”的参数将用于允许访问我们正在扩展的对象的实例。我不明白的是为什么不能将方法创建为静态的……在我看来，这是一个毫无意义的限制……

我的问题是：为什么我们不能创建一个可以作为静态方法工作的扩展方法？

【问题讨论】：

【解决方案1】：

我希望真正的答案很简单：没有一个好的用例。例如，优点是它可以在现有类型（它们本身不提供逻辑）上启用 fluent-API - 即

var foo = data.Where(x=>x.IsActive).OrderBy(x=>x.Price).First();

启用 LINQ：

var foo = (from x in data
           where x.IsActive
           order by x.Price
           select x).First();

使用静态方法，这根本不是问题，因此没有理由；只需对第二种类型使用静态方法即可。

事实上，扩展方法并不是正确地面向对象的——它们是一种务实的滥用，以牺牲纯度为代价让生活更轻松。没有理由以同样的方式稀释静态方法。

【讨论】：

【解决方案2】：

因为 C# 中不存在该功能。

作为一种解决方法，静态方法可以在另一个类中实现并通过该类调用以提供附加功能。

例如，XNA 有一个MathHelper 类，理想情况下它是Math 类的静态扩展。

如果我们认为这对 C# 4.0 来说是个好主意，社区是 asking

【讨论】：

重申您的主张：那是社区向社区提问。我认为 Max Payne 在这件事上并不代表微软。
很公平 ;-p 你关于 MathHelper 的观点非常有道理——我只是想知道它是否有足够的说服力足够进入。
我认为太多的开发人员已经习惯了这些“Helper”静态类。如果 C# 设计者同意使用静态方法来避免人们多次键入 Helper，我会感到惊讶。
请记住，扩展方法的一大好处是不再需要 Helper 静态类。
@Dustin;可以说，启用流畅的 API 使用更重要，这样你就有 foo.Bar().Blop()，而不是 Blop(Bar(foo)) - 但这根本不适用于静态。

【解决方案3】：

我的想法是为了兼容性 - 如果您突然将所有静态方法扩展方法都需要 this 运算符，您可能会无意中破坏现在正在使用扩展方法覆盖普通方法的代码。

this 参数允许控制，因此不会破坏兼容性。

只是一个想法。

【讨论】：

【解决方案4】：

首先，您必须添加另一种语法来表明您想要扩展现有类型的静态方法。扩展语法时，您确实需要一个很好的理由。

假设我有一个名为 MyExts 的类，它允许我向 MyClass 添加扩展方法。为什么会：-

MyClass.DoSomethingExtra();

优于

MyExts.DoSomethingExtra();

【讨论】：