为什么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;
    }

    ....

 }

当前回答

我的(简化的)技术原因是静态方法不在虚表中,调用站点是在编译时选择的。这和你不能有覆盖或虚拟静态成员的原因是一样的。要了解更多细节,你需要一个计算机专业毕业生或编译专家——而我两者都不是。

出于政治原因,我将引用Eric Lippert(他是一名编译器专家,拥有滑铁卢大学的数学、计算机科学和应用数学学士学位)的话:

...静态方法的核心设计原则,给它们命名的原则是…在编译时,总是可以准确地确定将调用什么方法。也就是说,可以仅通过对代码的静态分析来解析该方法。

请注意,Lippert确实为所谓的类型方法留出了空间:

也就是说,与类型相关联的方法(如静态方法),它不接受不可空的“this”参数(与实例或虚拟方法不同),而是调用的方法依赖于T的构造类型(与静态方法不同,它必须在编译时确定)。

但还没有被它的实用性所说服。

其他回答

静态类应该能够做到这一点,这样它们就可以被通用地使用。我不得不实现一个Singleton来实现预期的结果。

我有一堆静态业务层类,实现了CRUD方法,如“创建”,“读取”,“更新”,“删除”的每个实体类型,如“用户”,“团队”等。然后,我为实现CRUD方法的业务层类创建了一个具有抽象属性的基本控件。这让我可以自动从基类中执行“创建”、“读取”、“更新”、“删除”操作。由于静态限制,我不得不使用单例。

接口是一个OOPS概念,这意味着接口的每个成员都应该通过对象或实例得到使用。因此,接口不能有静态方法。

我认为简单的答案是“因为它毫无用处”。 要调用接口方法,需要该类型的实例。从实例方法中,您可以调用任何您想要的静态方法。

当类实现接口时,它是在为接口成员创建实例。虽然静态类型没有实例,但在接口中使用静态签名是没有意义的。

供您参考:您可以通过为接口创建扩展方法来获得与您想要的类似的行为。扩展方法将是一个共享的、不可覆盖的静态行为。然而,不幸的是,这个静态方法不是契约的一部分。