我认为简单的答案是“因为它毫无用处”。 要调用接口方法，需要该类型的实例。从实例方法中，您可以调用任何您想要的静态方法。

假设你在问为什么你不能这样做:

public interface IFoo {
    void Bar();
}

public class Foo: IFoo {
    public static void Bar() {}
}

This doesn't make sense to me, semantically. Methods specified on an interface should be there to specify the contract for interacting with an object. Static methods do not allow you to interact with an object - if you find yourself in the position where your implementation could be made static, you may need to ask yourself if that method really belongs in the interface. To implement your example, I would give Animal a const property, which would still allow it to be accessed from a static context, and return that value in the implementation.

public class Animal: IListItem {
    /* Can be tough to come up with a different, yet meaningful name!
     * A different casing convention, like Java has, would help here.
     */
    public const string AnimalScreenName = "Animal";
    public string ScreenName(){ return AnimalScreenName; }
}

对于更复杂的情况，您总是可以声明另一个静态方法并委托给它。在尝试给出一个例子的过程中，我想不出您在静态和实例上下文中都要做一些非平凡的事情的任何理由，因此我将给您一个FooBar blob，并将其作为它可能不是一个好主意的指示。

您可以将类的静态方法和非静态方法看作是不同的接口。调用时，静态方法解析为单例静态类对象，而非静态方法解析为所处理的类的实例。所以，如果你在一个接口中使用静态和非静态方法，你实际上是在声明两个接口，而实际上我们想要接口被用来访问一个内聚的东西。

在接口代表“契约”的程度上，静态类实现接口似乎是非常合理的。

上述论点似乎都忽略了合同的这一点。

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

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

例如:

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...
    }
  }
}

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

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

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