为什么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#语言实现，限制是由于允许继承基类和接口。如果“类SomeBaseClass”实现了“接口ISomeInterface”和“类SomeDerivedClass: SomeBaseClass, ISomeInterface”也实现了接口，实现接口方法的静态方法将会编译失败，因为静态方法不能与实例方法具有相同的签名(实例方法将出现在实现接口的基类中)。
静态类在功能上与单例类相同，并且具有与单例类相同的目的，只是语法更简洁。因为单例可以实现接口，所以静态的接口实现在概念上是有效的。
因此，这可以简单地归结为c#的实例名称冲突和跨继承的同名静态方法的限制。c#没有理由不能“升级”以支持静态方法契约(接口)。
我的(简化的)技术原因是静态方法不在虚表中，调用站点是在编译时选择的。这和你不能有覆盖或虚拟静态成员的原因是一样的。要了解更多细节，你需要一个计算机专业毕业生或编译专家——而我两者都不是。
出于政治原因，我将引用Eric Lippert(他是一名编译器专家，拥有滑铁卢大学的数学、计算机科学和应用数学学士学位)的话:
.．.静态方法的核心设计原则，给它们命名的原则是…在编译时，总是可以准确地确定将调用什么方法。也就是说，可以仅通过对代码的静态分析来解析该方法。
请注意，Lippert确实为所谓的类型方法留出了空间:
也就是说，与类型相关联的方法(如静态方法)，它不接受不可空的“this”参数(与实例或虚拟方法不同)，而是调用的方法依赖于T的构造类型(与静态方法不同，它必须在编译时确定)。
但还没有被它的实用性所说服。
