接口是Java 8中实用程序类的有效替代吗？ [英] Are interfaces a valid substitute for utility classes in Java 8?

问题描述

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

For the past decade or so, I've been using the pattern below for my Java utility classes. The class contains only static methods and fields, is declared final so it can't be extended, and has a private constructor so it can't be instantiated.

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

    private SomeUtilityClass() {}

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

        return null;
    }
}

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

Now, with the introduction of static methods in interfaces in Java 8, I lately find myself using a utility interface pattern:

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

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

        return null;
    }
}

这可以让我摆脱构造函数，很多关键字（ public ， static ， final ）在接口中是隐含的。

This allows me to get rid of the constructor, and a lot of keywords (public, static, final) that are implicit in interfaces.

这种方法有什么缺点吗？在实用程序界面上使用实用程序类有什么好处吗？

Are there any downsides to this approach? Are there any benefits to using a utility class over a utility interface?

推荐答案

基于创建常量接口模式的人反模式，我想说虽然你不打算让客户实现界面，但它仍然可能，可能更容易，而且不应该被允许：

Going based on the person who coined the Constant Interface pattern an anti-pattern, I would say although you don't intend the client(s) to implement the interface, it's still possible, possibly easier, and shouldn't be allowed:

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

虽然如下所述，但它确实如此取决于目标受众

Although as mentioned below, it really depends on the target audience

许多易于使用的设计模式受到很多批评（上下文模式，单例模式，恒定接口模式）。哎呀，即使是设计原则，如德米特定律因为过于冗长而受到批评。

A lot of easy-to-use designs patterns get a lot of criticism (Context pattern, Singleton pattern, Constant Interface pattern). Heck, even design principles such as the law of demeter gets criticised for being too verbose.

我讨厌说出来，但这些决定都是基于意见的。尽管上下文模式被视为一种反模式，但它在主流框架（如Spring和Android SDK ）中显而易见。它归结为环境以及目标受众。

I'd hate to say it, but these kinds of decisions are opinion based. Although the context pattern is seen as an anti-pattern, it's apparent in mainstream frameworks such as Spring and the Android SDK. It boils down to the environment, as well as target audience.

我能找到的主要缺点被列为第三个清单 Constant Interface wiki 中的缺点：

The main downside that I can find is listed as the third listing under "downsides" in the Constant Interface wiki:

如果在将来的版本中需要二进制代码兼容性，则常量接口必须永远保留一个接口（它不能转换为类），即使它没有被用作传统意义上的界面。

如果你想过嘿，这实际上不是合同而我想要强化更强的设计，你将无法改变它。但正如我所说，这取决于你;也许你不会在将来改变它。

If you ever figure "Hey, this actually isn't a contract and I want to enforce stronger design", you will not be able to change it. But as I've said, it's up to you; maybe you won't care to change it in the future.

最重要的是，@ TagirValeev提到的代码清晰度。接口的目的是实现;如果您不希望某人实施您提供的API，请不要使其可实现。但我相信这围绕着目标受众的声明。不会撒谎，我和你在一个不那么冗长的基础上，但这取决于我的代码是谁;不希望对可能被审查的代码使用常量接口。

On top of that, code clarity as mentioned by @TagirValeev. Interfaces have the intent of being implemented; if you don't want someone to implement the API you're supplying, don't make it implementable. But I believe this revolves around the "target audience" statement. Not gonna lie, I'm with you on the less-verbose foundation, but it depends on who my code is for; wouldn't wanna use a constant interface for code that may get reviewed.

这篇关于接口是Java 8中实用程序类的有效替代吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！