Regarding static methods used in non-generic contexts I agree that it doesn't make much sense to allow them in interfaces, since you wouldn't be able to call them if you had a reference to the interface anyway. However there is a fundamental hole in the language design created by using interfaces NOT in a polymorphic context, but in a generic one. In this case the interface is not an interface at all but rather a constraint. Because C# has no concept of a constraint outside of an interface it is missing substantial functionality. Case in point:

T SumElements<T>(T initVal, T[] values)
{
    foreach (var v in values)
    {
        initVal += v;
    }
}

这里没有多态性，泛型使用对象的实际类型并调用+=操作符，但这失败了，因为它不能确定该操作符是否存在。简单的解决方案是在约束中指定它;简单的解决方案是不可能的，因为操作符是静态的，静态方法不能在接口中，(这就是问题所在)约束被表示为接口。

c#需要的是一个真正的约束类型，所有的接口都是约束，但不是所有的约束都是接口，然后你可以这样做:

constraint CHasPlusEquals
{
    static CHasPlusEquals operator + (CHasPlusEquals a, CHasPlusEquals b);
}

T SumElements<T>(T initVal, T[] values) where T : CHasPlusEquals
{
    foreach (var v in values)
    {
        initVal += v;
    }
}

已经有很多关于为所有数字类型创建i算术来实现的讨论，但是存在效率问题，因为约束不是多态构造，所以创建算术约束可以解决这个问题。

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

举一个例子，我既没有接口方法的静态实现，也没有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，实例化一个实例的开销是最小的。但是，在这种情况下它会很好。

I think the question is getting at the fact that C# needs another keyword, for precisely this sort of situation. You want a method whose return value depends only on the type on which it is called. You can't call it "static" if said type is unknown. But once the type becomes known, it will become static. "Unresolved static" is the idea -- it's not static yet, but once we know the receiving type, it will be. This is a perfectly good concept, which is why programmers keep asking for it. But it didn't quite fit into the way the designers thought about the language.

因为它不可用，所以我采用如下所示的方式使用非静态方法。虽然不太理想，但至少对我来说，我找不到比这更有意义的方法了。

public interface IZeroWrapper<TNumber> {
  TNumber Zero {get;}
}

public class DoubleWrapper: IZeroWrapper<double> {
  public double Zero { get { return 0; } }
}

因为接口是继承结构，静态方法继承不好。

Regarding static methods used in non-generic contexts I agree that it doesn't make much sense to allow them in interfaces, since you wouldn't be able to call them if you had a reference to the interface anyway. However there is a fundamental hole in the language design created by using interfaces NOT in a polymorphic context, but in a generic one. In this case the interface is not an interface at all but rather a constraint. Because C# has no concept of a constraint outside of an interface it is missing substantial functionality. Case in point:

T SumElements<T>(T initVal, T[] values)
{
    foreach (var v in values)
    {
        initVal += v;
    }
}

这里没有多态性，泛型使用对象的实际类型并调用+=操作符，但这失败了，因为它不能确定该操作符是否存在。简单的解决方案是在约束中指定它;简单的解决方案是不可能的，因为操作符是静态的，静态方法不能在接口中，(这就是问题所在)约束被表示为接口。

c#需要的是一个真正的约束类型，所有的接口都是约束，但不是所有的约束都是接口，然后你可以这样做:

constraint CHasPlusEquals
{
    static CHasPlusEquals operator + (CHasPlusEquals a, CHasPlusEquals b);
}

T SumElements<T>(T initVal, T[] values) where T : CHasPlusEquals
{
    foreach (var v in values)
    {
        initVal += v;
    }
}

已经有很多关于为所有数字类型创建i算术来实现的讨论，但是存在效率问题，因为约束不是多态构造，所以创建算术约束可以解决这个问题。