c#和CLR应该像Java一样支持接口中的静态方法。静态修饰符是契约定义的一部分，确实有意义，具体来说，行为和返回值不会基于实例而变化，尽管在不同调用之间仍然可能不同。

也就是说，当您想在接口中使用静态方法而又不能使用时，我建议您使用注释。您将得到您正在寻找的功能。

静态类应该能够做到这一点，这样它们就可以被通用地使用。我不得不实现一个Singleton来实现预期的结果。

我有一堆静态业务层类，实现了CRUD方法，如“创建”，“读取”，“更新”，“删除”的每个实体类型，如“用户”，“团队”等。然后，我为实现CRUD方法的业务层类创建了一个具有抽象属性的基本控件。这让我可以自动从基类中执行“创建”、“读取”、“更新”、“删除”操作。由于静态限制，我不得不使用单例。

这里的大多数答案似乎都没有抓住重点。多态性不仅可以在实例之间使用，还可以在类型之间使用。当我们使用泛型时，这是经常需要的。

假设我们在泛型方法中有类型参数，我们需要对它做一些操作。我们不想实例化，因为我们不知道构造函数。

例如:

Repository GetRepository<T>()
{
  //need to call T.IsQueryable, but can't!!!
  //need to call T.RowCount
  //need to call T.DoSomeStaticMath(int param)
}

...
var r = GetRepository<Customer>()

不幸的是，我只能想出一些“丑陋”的选择:

Use reflection Ugly and beats the idea of interfaces and polymorphism. Create completely separate factory class This might greatly increase the complexity of the code. For example, if we are trying to model domain objects, each object would need another repository class. Instantiate and then call the desired interface method This can be hard to implement even if we control the source for the classes, used as generic parameters. The reason is that, for example we might need the instances to be only in well-known, "connected to DB" state.

例子:

public class Customer 
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  void SomeOtherMethod() 
  { 
    //do work...
  }
}

为了使用实例化来解决静态接口问题，我们需要做以下事情:

public class Customer: IDoSomeStaticMath
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  //dummy instance
  public Customer() { IsDummy = true; }

  int DoSomeStaticMath(int a) { }

  void SomeOtherMethod() 
  { 
    if(!IsDummy) 
    {
      //do work...
    }
  }
}

这显然是丑陋的，也是不必要的，会使所有其他方法的代码复杂化。显然，这也不是一个优雅的解决方案!

因为接口的目的是允许多态性，能够传递任意数量的已定义类的实例，这些类都已定义，以实现已定义的接口……确保在多态调用中，代码能够找到您正在调用的方法。允许静态方法实现接口是没有意义的，

你怎么称呼它??

public interface MyInterface { void MyMethod(); }
public class MyClass: MyInterface
{
    public static void MyMethod() { //Do Something; }
}

 // inside of some other class ...  
 // How would you call the method on the interface ???
    MyClass.MyMethod();  // this calls the method normally 
                         // not through the interface...

    // This next fails you can't cast a classname to a different type... 
    // Only instances can be Cast to a different type...
    MyInterface myItf = MyClass as MyInterface;  

这里有一个需要类型方法的例子。我正在创建一组基于源XML的类之一。所以我有一个

  static public bool IsHandled(XElement xml)

函数，在每个类上依次调用。

函数应该是静态的，否则我们会浪费时间创建不合适的对象。 正如@Ian Boyde指出的那样，它可以在工厂类中完成，但这只会增加复杂性。

最好将它添加到接口中，以强制类实现者实现它。这不会造成很大的开销——它只是一个编译/链接时间检查，不会影响虚表。

然而，这也将是一个相当小的改进。由于方法是静态的，我作为调用者，必须显式地调用它，因此如果它没有实现，就会立即得到编译错误。允许在接口上指定它将意味着这个错误在开发周期中稍微提前出现，但与其他损坏的接口问题相比，这是微不足道的。

所以这是一个次要的潜在特性，总的来说最好还是忽略不计。

接口是已定义可用功能的抽象集合。

该接口中的方法是否表现为静态行为是应该隐藏在接口后面的实现细节。将接口方法定义为静态是错误的，因为您将不必要地强制该方法以某种方式实现。

如果方法被定义为静态的，那么实现接口的类就不会像它应该的那样被封装。在面向对象设计中，封装是一件值得努力的事情(我不会详细说明原因，你可以在这里阅读:http://en.wikipedia.org/wiki/Object-oriented)。因此，在接口中不允许使用静态方法。