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

您想要的是允许通过Type或该类型的任何实例调用静态方法。这至少会导致歧义，这不是一个理想的特征。

关于这是否重要，这是最佳实践，以及这样做是否存在性能问题，将会有无休止的争论。通过简单地不支持它，c#使我们不必担心它。

遵循这一愿望的编译器也可能会失去一些优化，而这些优化可能会带来实例方法和静态方法之间更严格的分离。

举一个例子，我既没有接口方法的静态实现，也没有Mark Brackett介绍的“所谓的类型方法”:

当从数据库存储中读取数据时，我们有一个通用的DataTable类来处理从任何结构的表中读取数据。所有特定于表的信息都放在每个表的一个类中，每个表还保存来自DB的一行的数据，并且必须实现IDataRow接口。IDataRow中包含了要从数据库中读取的表的结构描述。DataTable在从DB中读取数据之前必须向IDataRow请求数据结构。目前看起来是这样的:

interface IDataRow {
  string GetDataSTructre();  // How to read data from the DB
  void Read(IDBDataRow);     // How to populate this datarow from DB data
}

public class DataTable<T> : List<T> where T : IDataRow {

  public string GetDataStructure()
    // Desired: Static or Type method:
    // return (T.GetDataStructure());
    // Required: Instantiate a new class:
    return (new T().GetDataStructure());
  }

}

每个表只需要读取一次GetDataStructure，实例化一个实例的开销是最小的。但是，在这种情况下它会很好。

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

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

我的(简化的)技术原因是静态方法不在虚表中，调用站点是在编译时选择的。这和你不能有覆盖或虚拟静态成员的原因是一样的。要了解更多细节，你需要一个计算机专业毕业生或编译专家——而我两者都不是。

出于政治原因，我将引用Eric Lippert(他是一名编译器专家，拥有滑铁卢大学的数学、计算机科学和应用数学学士学位)的话:

.．.静态方法的核心设计原则，给它们命名的原则是…在编译时，总是可以准确地确定将调用什么方法。也就是说，可以仅通过对代码的静态分析来解析该方法。

请注意，Lippert确实为所谓的类型方法留出了空间:

也就是说，与类型相关联的方法(如静态方法)，它不接受不可空的“this”参数(与实例或虚拟方法不同)，而是调用的方法依赖于T的构造类型(与静态方法不同，它必须在编译时确定)。

但还没有被它的实用性所说服。

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

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，并将其作为它可能不是一个好主意的指示。