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

    ....

 }

当前回答

您可以将类的静态方法和非静态方法看作是不同的接口。调用时,静态方法解析为单例静态类对象,而非静态方法解析为所处理的类的实例。所以,如果你在一个接口中使用静态和非静态方法,你实际上是在声明两个接口,而实际上我们想要接口被用来访问一个内聚的东西。

其他回答

在接口代表“契约”的程度上,静态类实现接口似乎是非常合理的。

上述论点似乎都忽略了合同的这一点。

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

我猜这是短视。

在最初设计时,接口仅用于类的实例

IMyInterface val = GetObjectImplementingIMyInterface();
val.SomeThingDefinedinInterface();

只有引入接口作为泛型的约束,向接口中添加静态方法才有实际用途。

(回复评论:)我认为现在更改它需要更改CLR,这将导致与现有程序集不兼容。

这里有一个需要类型方法的例子。我正在创建一组基于源XML的类之一。所以我有一个

  static public bool IsHandled(XElement xml)

函数,在每个类上依次调用。

函数应该是静态的,否则我们会浪费时间创建不合适的对象。 正如@Ian Boyde指出的那样,它可以在工厂类中完成,但这只会增加复杂性。

最好将它添加到接口中,以强制类实现者实现它。这不会造成很大的开销——它只是一个编译/链接时间检查,不会影响虚表。

然而,这也将是一个相当小的改进。由于方法是静态的,我作为调用者,必须显式地调用它,因此如果它没有实现,就会立即得到编译错误。允许在接口上指定它将意味着这个错误在开发周期中稍微提前出现,但与其他损坏的接口问题相比,这是微不足道的。

所以这是一个次要的潜在特性,总的来说最好还是忽略不计。

一个静态类是用c#实现的,微软用静态元素创建了一个特殊的类实例,这只是实现静态功能的一个奇怪之处。这不是一个理论观点。

接口应该是类接口的描述符——或者它是如何与之交互的,并且应该包括静态的交互。接口的一般定义(来自merriam - webster):不同事物相遇、交流或相互影响的地方或区域。当您完全忽略类的静态组件或静态类时,我们就忽略了这些坏家伙如何交互的大部分内容。

下面是一个非常清晰的例子,说明了在静态类中使用接口是非常有用的:

public interface ICrudModel<T, Tk>
{
    Boolean Create(T obj);
    T Retrieve(Tk key);
    Boolean Update(T obj);
    Boolean Delete(T obj);
}

目前,我在编写包含这些方法的静态类时没有进行任何检查,以确保我没有忘记任何东西。就像在面向对象编程之前的糟糕的编程时代。