为什么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;
}
....
}
我知道这是个老问题，但很有趣。这个例子并不是最好的。我认为如果你展示一个用例会更清楚:
string DoSomething<T>() where T:ISomeFunction
{
if (T.someFunction())
...
}
仅仅使用静态方法实现接口并不能达到你想要的效果;所需要的是将静态成员作为接口的一部分。我当然可以想象出许多用例，特别是当它能够创建东西的时候。我可以提供两种可能有用的方法:
Create a static generic class whose type parameter will be the type you'd be passing to DoSomething above. Each variation of this class will have one or more static members holding stuff related to that type. This information could supplied either by having each class of interest call a "register information" routine, or by using Reflection to get the information when the class variation's static constructor is run. I believe the latter approach is used by things like Comparer<T>.Default().
For each class T of interest, define a class or struct which implements IGetWhateverClassInfo<T> and satisfies a "new" constraint. The class won't actually contain any fields, but will have a static property which returns a static field with the type information. Pass the type of that class or struct to the generic routine in question, which will be able to create an instance and use it to get information about the other class. If you use a class for this purpose, you should probably define a static generic class as indicated above, to avoid having to construct a new descriptor-object instance each time. If you use a struct, instantiation cost should be nil, but every different struct type would require a different expansion of the DoSomething routine.
这些方法都不太吸引人。另一方面，我希望如果CLR中存在能够干净地提供这类功能的机制，.net将允许指定参数化的“new”约束(因为知道一个类是否具有具有特定签名的构造函数似乎与知道它是否具有具有特定签名的静态方法在难度上相当)。
我的(简化的)技术原因是静态方法不在虚表中，调用站点是在编译时选择的。这和你不能有覆盖或虚拟静态成员的原因是一样的。要了解更多细节，你需要一个计算机专业毕业生或编译专家——而我两者都不是。
出于政治原因，我将引用Eric Lippert(他是一名编译器专家，拥有滑铁卢大学的数学、计算机科学和应用数学学士学位)的话:
.．.静态方法的核心设计原则，给它们命名的原则是…在编译时，总是可以准确地确定将调用什么方法。也就是说，可以仅通过对代码的静态分析来解析该方法。
请注意，Lippert确实为所谓的类型方法留出了空间:
也就是说，与类型相关联的方法(如静态方法)，它不接受不可空的“this”参数(与实例或虚拟方法不同)，而是调用的方法依赖于T的构造类型(与静态方法不同，它必须在编译时确定)。
但还没有被它的实用性所说服。
假设你在问为什么你不能这样做:
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，并将其作为它可能不是一个好主意的指示。
