有几个答案讨论了可覆盖静态方法概念的问题。然而，有时你会遇到一种模式，它似乎正是你想要使用的。

例如，我使用对象关系层，该层有值对象，但也有用于操作值对象的命令。由于各种原因，每个值对象类都必须定义一些静态方法，以便框架找到命令实例。例如，要创建一个Person，你可以这样做:

cmd = createCmd(Person.getCreateCmdId());
Person p = cmd.execute();

通过ID加载Person

cmd = createCmd(Person.getGetCmdId());
cmd.set(ID, id);
Person p = cmd.execute();

这是相当方便的，但它有它的问题;值得注意的是，静态方法的存在不能在接口中强制执行。接口中可覆盖的静态方法正是我们所需要的，只要它能以某种方式工作。

EJBs solve this problem by having a Home interface; each object knows how to find its Home and the Home contains the "static" methods. This way the "static" methods can be overridden as needed, and you don't clutter up the normal (it's called "Remote") interface with methods that don't apply to an instance of your bean. Just make the normal interface specify a "getHome()" method. Return an instance of the Home object (which could be a singleton, I suppose) and the caller can perform operations that affect all Person objects.

我认为java没有静态接口方法，因为你不需要它们。你可能认为你知道，但是… 你会如何使用它们?如果你想叫他们

MyImplClass.myMethod()

那么就不需要在接口中声明它了。如果你想叫他们

myInstance.myMethod()

那么它就不应该是静态的。 如果您实际上打算使用第一种方法，但只是想强制每个实现都有这样的静态方法，那么它实际上是一种编码约定，而不是实现接口的实例和调用代码之间的契约。

接口允许您在实现接口的类实例和调用代码之间定义契约。java帮助您确保这个契约没有被违反，因此您可以依赖它，而不必担心哪个类实现了这个契约，只要“某个签署了契约的人”就足够了。在静态接口的情况下，你的代码

MyImplClass.myMethod()

不依赖于每个接口实现都有此方法的事实，因此不需要Java来帮助您确定使用它。

静态方法不像实例方法那样是虚拟的，所以我猜想Java设计者决定不让它们出现在接口中。

但是您可以将包含静态方法的类放在接口中。你可以试试!

public interface Test {
    static class Inner {
        public static Object get() {
            return 0;
        }
    }
}

“是否有一个特殊的原因，静态方法不能被覆盖”。

让我把这个问题重新定义一下。

“在编译时解析的方法不能在运行时解析，是否有特殊原因?”

或者，更完整地说，如果我想在没有实例的情况下调用一个方法，但知道这个类，我怎么能根据我没有的实例来解析它呢?

可以实现的是静态接口(而不是接口中的静态方法)。实现给定静态接口的所有类都应该实现相应的静态方法。你可以从任何Class clazz中获得静态接口SI

SI si = clazz.getStatic(SI.class); // null if clazz doesn't implement SI
// alternatively if the class is known at compile time
SI si = Someclass.static.SI; // either compiler errror or not null

然后你可以调用si.method(params)。 这将很有用(例如对于工厂设计模式)，因为您可以从编译时未知类获得(或检查)SI静态方法实现! 动态分派是必要的，您可以通过扩展类(当通过静态接口调用时)来重写类的静态方法(如果不是final方法)。 显然，这些方法只能访问它们类的静态变量。

First, all language decisions are decisions made by the language creators. There is nothing in the world of software engineering or language defining or compiler / interpreter writing which says that a static method cannot be part of an interface. I've created a couple of languages and written compilers for them -- it's all just sitting down and defining meaningful semantics. I'd argue that the semantics of a static method in an interface are remarkably clear -- even if the compiler has to defer resolution of the method to run-time.

其次，我们使用静态方法意味着有一个包含静态方法的接口模式的正当理由——我不能代表你们，但我经常使用静态方法。

The most likely correct answer is that there was no perceived need, at the time the language was defined, for static methods in interfaces. Java has grown a lot over the years and this is an item that has apparently gained some interest. That it was looked at for Java 7 indicates that its risen to a level of interest that might result in a language change. I, for one, will be happy when I no longer have to instantiate an object just so I can call my non-static getter method to access a static variable in a subclass instance ...