为什么c#是这样设计的?
根据我的理解，一个接口只描述行为，并且服务于描述实现接口的类的契约义务。
如果类希望在共享方法中实现这种行为，为什么不应该呢?
以下是我想到的一个例子:
// These items will be displayed in a list on the screen.
public interface IListItem {
string ScreenName();
...
}
public class Animal: IListItem {
// All animals will be called "Animal".
public static string ScreenName() {
return "Animal";
}
....
}
public class Person: IListItem {
private string name;
// All persons will be called by their individual names.
public string ScreenName() {
return name;
}
....
}
一个静态类是用c#实现的，微软用静态元素创建了一个特殊的类实例，这只是实现静态功能的一个奇怪之处。这不是一个理论观点。
接口应该是类接口的描述符——或者它是如何与之交互的，并且应该包括静态的交互。接口的一般定义(来自merriam - webster):不同事物相遇、交流或相互影响的地方或区域。当您完全忽略类的静态组件或静态类时，我们就忽略了这些坏家伙如何交互的大部分内容。
下面是一个非常清晰的例子，说明了在静态类中使用接口是非常有用的:
public interface ICrudModel<T, Tk>
{
Boolean Create(T obj);
T Retrieve(Tk key);
Boolean Update(T obj);
Boolean Delete(T obj);
}
目前，我在编写包含这些方法的静态类时没有进行任何检查，以确保我没有忘记任何东西。就像在面向对象编程之前的糟糕的编程时代。
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算术来实现的讨论，但是存在效率问题，因为约束不是多态构造，所以创建算术约束可以解决这个问题。
