为什么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;
}
....
}
假设你在问为什么你不能这样做:
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，并将其作为它可能不是一个好主意的指示。
事实上，确实如此。
截至2022年年中，当前版本的c#完全支持所谓的静态抽象成员:
interface INumber<T>
{
static abstract T Zero { get; }
}
struct Fraction : INumber<Fraction>
{
public static Fraction Zero { get; } = new Fraction();
public long Numerator;
public ulong Denominator;
....
}
请注意，根据你的Visual Studio版本和你安装的。net SDK，你必须至少更新其中一个(或两个)，或者你必须启用预览功能(参见在Visual Studio中使用预览功能和预览语言)。
看到更多:
https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/static-virtual-interface-members
https://blog.ndepend.com/c-11-static-abstract-members/
https://khalidabuhakmeh.com/static-abstract-members-in-csharp-10-interfaces: ~:文本=静态% 20文摘% 20成员% 20允许% 20,像% 20 % 20其他% 20接口% 20的定义。
从概念上讲，接口没有理由不能定义包含静态方法的契约。
对于当前的c#语言实现，限制是由于允许继承基类和接口。如果“类SomeBaseClass”实现了“接口ISomeInterface”和“类SomeDerivedClass: SomeBaseClass, ISomeInterface”也实现了接口，实现接口方法的静态方法将会编译失败，因为静态方法不能与实例方法具有相同的签名(实例方法将出现在实现接口的基类中)。
静态类在功能上与单例类相同，并且具有与单例类相同的目的，只是语法更简洁。因为单例可以实现接口，所以静态的接口实现在概念上是有效的。
因此，这可以简单地归结为c#的实例名称冲突和跨继承的同名静态方法的限制。c#没有理由不能“升级”以支持静态方法契约(接口)。
这里有一个需要类型方法的例子。我正在创建一组基于源XML的类之一。所以我有一个
static public bool IsHandled(XElement xml)
函数，在每个类上依次调用。
函数应该是静态的，否则我们会浪费时间创建不合适的对象。
正如@Ian Boyde指出的那样，它可以在工厂类中完成，但这只会增加复杂性。
最好将它添加到接口中，以强制类实现者实现它。这不会造成很大的开销——它只是一个编译/链接时间检查，不会影响虚表。
然而，这也将是一个相当小的改进。由于方法是静态的，我作为调用者，必须显式地调用它，因此如果它没有实现，就会立即得到编译错误。允许在接口上指定它将意味着这个错误在开发周期中稍微提前出现，但与其他损坏的接口问题相比，这是微不足道的。
所以这是一个次要的潜在特性，总的来说最好还是忽略不计。
