为什么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#实现的，微软用静态元素创建了一个特殊的类实例，这只是实现静态功能的一个奇怪之处。这不是一个理论观点。
接口应该是类接口的描述符——或者它是如何与之交互的，并且应该包括静态的交互。接口的一般定义(来自merriam - webster):不同事物相遇、交流或相互影响的地方或区域。当您完全忽略类的静态组件或静态类时，我们就忽略了这些坏家伙如何交互的大部分内容。
下面是一个非常清晰的例子，说明了在静态类中使用接口是非常有用的:
public interface ICrudModel<T, Tk>
{
Boolean Create(T obj);
T Retrieve(Tk key);
Boolean Update(T obj);
Boolean Delete(T obj);
}
目前，我在编写包含这些方法的静态类时没有进行任何检查，以确保我没有忘记任何东西。就像在面向对象编程之前的糟糕的编程时代。
举一个例子，我既没有接口方法的静态实现，也没有Mark Brackett介绍的“所谓的类型方法”:
当从数据库存储中读取数据时，我们有一个通用的DataTable类来处理从任何结构的表中读取数据。所有特定于表的信息都放在每个表的一个类中，每个表还保存来自DB的一行的数据，并且必须实现IDataRow接口。IDataRow中包含了要从数据库中读取的表的结构描述。DataTable在从DB中读取数据之前必须向IDataRow请求数据结构。目前看起来是这样的:
interface IDataRow {
string GetDataSTructre(); // How to read data from the DB
void Read(IDBDataRow); // How to populate this datarow from DB data
}
public class DataTable<T> : List<T> where T : IDataRow {
public string GetDataStructure()
// Desired: Static or Type method:
// return (T.GetDataStructure());
// Required: Instantiate a new class:
return (new T().GetDataStructure());
}
}
每个表只需要读取一次GetDataStructure，实例化一个实例的开销是最小的。但是，在这种情况下它会很好。
