接口是Java 8中实用程序类的有效替代品吗？[重复]

Question

在过去十年左右的时间里，我一直在将以下模式用于Java实用程序类。该类仅包含静态方法和字段，已声明final为无法扩展，并且具有private构造函数因此无法实例化。

public final class SomeUtilityClass {
    public static final String SOME_CONSTANT = "Some constant";

    private SomeUtilityClass() {}

    public static Object someUtilityMethod(Object someParameter) {
        /* ... */

        return null;
    }
}

现在，随着Java 8
接口中静态方法的引入，我最近发现自己使用了实用程序接口模式：

public interface SomeUtilityInterface {
    String SOME_CONSTANT = "Some constant";

    static Object someUtilityMethod(Object someParameter) {
        /* ... */

        return null;
    }
}

这使我摆脱构造，和大量的关键字（个public，static，final），这些接口中隐含的。

这种方法有不利之处吗？通过实用程序接口使用实用程序类有什么好处？

Answer 1

以为Constant Interface模式创建反模式的人为基础，我想说，尽管您不打算让客户端实现该接口，但它仍然有可能，可能更容易并且 不应被允许
：

API应该易于使用且难以滥用。做简单的事情应该很容易；可能做复杂的事情； 并且不可能或至少很难做错事。

尽管如下所述，但这确实取决于目标受众

许多易于使用的设计模式都受到了很多批评（上下文模式，单例模式，常量接口模式）。哎呀，甚至像得墨meter耳定律这样的设计原则也因过于冗长而受到批评。

我不想这么说，但是这些决定都是基于意见的。尽管上下文模式被视为一种反模式， 但在诸如Spring和Android SDK之类的主流框架中很明显
。它归结为环境以及目标受众。

我可以找到的主要缺点 是在Constant Interface
wiki中的“缺点”下列出的第三项内容：

如果将来的发行版中要求二进制代码兼容，则常量接口必须永远保持一个接口（无法将其转换为类）， 即使它在常规意义上并未用作接口。

如果您曾经想过“嘿，这实际上不是合同，我想执行更强大的设计”，则您将无法对其进行更改。但正如我所说，这取决于您；也许您将来不会在意​​更改它。

最重要的是，@
TagirValeev提到的代码清晰度。接口的目的是实现；如果您不希望某人实现您提供的API，请不要使其实现。但是，我认为这与“目标受众”声明有关。不会撒谎，我会在不太冗长的基础上与您同在，但这取决于我的代码适用于谁。不想使用可能会被检查的代码的常量接口。