为什么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;
}
....
}
这里有一个需要类型方法的例子。我正在创建一组基于源XML的类之一。所以我有一个
static public bool IsHandled(XElement xml)
函数，在每个类上依次调用。
函数应该是静态的，否则我们会浪费时间创建不合适的对象。
正如@Ian Boyde指出的那样，它可以在工厂类中完成，但这只会增加复杂性。
最好将它添加到接口中，以强制类实现者实现它。这不会造成很大的开销——它只是一个编译/链接时间检查，不会影响虚表。
然而，这也将是一个相当小的改进。由于方法是静态的，我作为调用者，必须显式地调用它，因此如果它没有实现，就会立即得到编译错误。允许在接口上指定它将意味着这个错误在开发周期中稍微提前出现，但与其他损坏的接口问题相比，这是微不足道的。
所以这是一个次要的潜在特性，总的来说最好还是忽略不计。
我的(简化的)技术原因是静态方法不在虚表中，调用站点是在编译时选择的。这和你不能有覆盖或虚拟静态成员的原因是一样的。要了解更多细节，你需要一个计算机专业毕业生或编译专家——而我两者都不是。
出于政治原因，我将引用Eric Lippert(他是一名编译器专家，拥有滑铁卢大学的数学、计算机科学和应用数学学士学位)的话:
.．.静态方法的核心设计原则，给它们命名的原则是…在编译时，总是可以准确地确定将调用什么方法。也就是说，可以仅通过对代码的静态分析来解析该方法。
请注意，Lippert确实为所谓的类型方法留出了空间:
也就是说，与类型相关联的方法(如静态方法)，它不接受不可空的“this”参数(与实例或虚拟方法不同)，而是调用的方法依赖于T的构造类型(与静态方法不同，它必须在编译时确定)。
但还没有被它的实用性所说服。
从概念上讲，接口没有理由不能定义包含静态方法的契约。
对于当前的c#语言实现，限制是由于允许继承基类和接口。如果“类SomeBaseClass”实现了“接口ISomeInterface”和“类SomeDerivedClass: SomeBaseClass, ISomeInterface”也实现了接口，实现接口方法的静态方法将会编译失败，因为静态方法不能与实例方法具有相同的签名(实例方法将出现在实现接口的基类中)。
静态类在功能上与单例类相同，并且具有与单例类相同的目的，只是语法更简洁。因为单例可以实现接口，所以静态的接口实现在概念上是有效的。
因此，这可以简单地归结为c#的实例名称冲突和跨继承的同名静态方法的限制。c#没有理由不能“升级”以支持静态方法契约(接口)。
