“静态接口”是一种好习惯吗？

我刚刚注意到，在接口中可以选择使用静态方法。与接口的静态字段相同，有一个有趣的行为：这些不是继承的。

我不确定它在要实现的实际接口中是否有用。但是，它使程序员能够创建仅仅是静态内容的信封的接口，例如实用程序类。

一个简单的例子只是全局常量的包络。与班级相比，您可以轻松地注意到public static final那些假定的样板丢失了（使它不太冗长）。

public interface Constants {
    String LOG_MESSAGE_FAILURE = "I took an arrow to the knee.";
    int DEFAULT_TIMEOUT_MS = 30;
}

您还可以使事情变得更复杂，例如配置键的伪枚举。

public interface ConfigKeys {
    static createValues(ConfigKey<?>... values) {
        return Collections.unmodifiableSet(new HashSet(Arrays.asList(values)));
    }

    static ConfigKey<T> key(Class<T> clazz) {
        return new ConfigKey<>(clazz);
    }

    class ConfigKey<T> {
        private final Class<T> type;
        private ConfigKey(Class<T> type) {
            this.type = type;
        }
        private Class<T> getType() {
            return type;
        }
    }
}

import static ConfigKeys.*;
public interface MyAppConfigKeys {
    ConfigKey<Boolean> TEST_MODE = key(Boolean.class);
    ConfigKey<String> COMPANY_NAME = key(String.class);

    Set<ConfigKey<?>> VALUES = createValues(TEST_MODE, COMPANY_VALUE);

    static values() {
        return VALUES;
    }
}

您也可以通过这种方式创建一些实用程序“类”。但是，在实用程序中，使用私有或受保护的助手方法通常很有用，而在类中却不太可能。

我认为这是一个不错的新功能，尤其是静态成员没有被继承的事实是一个有趣的概念，仅引入接口。

我想知道您是否可以认为这是一个好习惯。虽然代码风格和最佳实践不是不言而喻的，并且仍有意见的余地，但我认为通常有充分的理由支持意见。

我对使用这两种模式的原因（而不是原因）更感兴趣。

请注意，我不打算实现这些接口。它们仅仅是其静态内容的信封。我只打算使用常量或方法，并且可能使用静态导入。

一个简单的例子只是全局常量的包络。

将常量放在接口上之所以称为，是Constant Interface Antipattern因为常量通常只是实现细节。常量界面上的Wikipedia文章总结了其他缺点。

您也可以通过这种方式创建一些实用程序“类”。

确实，Java文档指出，静态方法可以使组织帮助程序方法更加容易，例如，从默认方法调用帮助程序方法时。

如问题中所述，该接口并不旨在实现（或实例化）。因此，我们可以将其与具有私有构造函数的类进行比较：

• 不能通过no super()调用来扩展该类，但是可以“实现”接口
• 没有反射就无法实例化该类，而可以像这样简单地将接口轻松实例化为一个匿名类： new MyInterface() {};

这种比较有利于类，因为它允许更多的控制。就是说，类也不打算成为静态对象的持有者，您希望它具有实例。好吧，没有完美的选择。

关于从“静态接口”继承的问题也很奇怪：

• “实现”类继承字段，但不继承静态方法
• 扩展接口根本不继承任何静态成员
• （虽然扩展类的类继承了每个非私有成员……并且由于不能通过接口进行扩展，所以混淆的空间较小）

这些可能是将其视为错误模式并在这些情况下继续使用静态类的原因。但是，对于沉迷于语法糖的人来说，即使有不利因素，也可能仍然很诱人。

与@MarkusPscheidt一样，这个想法本质上是Constant Interface反模式的扩展。最初，这种方法被广泛使用，以允许许多不同的类继承一组常量。之所以将其视为反模式，是因为在实际项目中使用此方法遇到的问题。我没有理由认为这些问题仅与常数有关。

可能更重要的是，实际上没有必要这样做。请改用静态导入，并明确说明要导入的内容以及从何处导入。

我想说的是，如果您对如何正确使用新功能感兴趣，请查看JDK中的代码。接口上的默认方法使用非常广泛，并且很容易找到，但是接口上的静态方法似乎很少见。一些例子包括java.time.chrono.Chronology，java.util.Comparator，java.util.Map，和不少在接口java.util.function和java.util.stream。

我看过的大多数示例都涉及到这些API的使用，这些API可能很常见：例如，时间API中不同类型之间的转换，例如，可能经常在传递给函数的对象或包含在其中的对象之间进行比较。集合。我的要点：如果您的API的一部分需要灵活，但是您可以使用一些默认值覆盖80％的用例，请考虑在接口上使用静态方法。鉴于此功能似乎很少在JDK中使用，因此在我自己的代码中使用它时，我会非常保守。

您的示例看起来并不像我在JDK中看到的那样。对于这些特定情况，几乎应该确定要创建一个enum实现所需接口的。接口描述了一组行为，实际上没有业务维护其实现的集合。

我想知道是否有理由不使用它。

嗯，与旧版JVM的兼容性如何？

您一般认为这是个好主意吗？

否。这是一种向后不兼容的更改，使语言的表现力更加明显。两个大拇指朝下。

在某些模型情况下，强烈建议您上课吗？

我强烈建议使用类来包含实现细节。一个接口实际上只是说“此对象支持XYZ操作”，它与您可能考虑放入接口声明中的任何静态方法无关。此功能就像带有内置迷你冰箱的躺椅。当然，它有一些利基用途，但它的重量不足以成为主流。

更新：请不要再投票。显然，有些人认为接口中的静态方法是蜜蜂的膝盖，在此我投降了。我将尽快删除此答案，但所附的评论是一个有趣的讨论。