Java 8:使用静态方法而不是静态 util 类的接口
当我需要一堆无状态实用程序方法时,Java 8中的最佳实践是什么?拥有一个不会由任何人实现的接口是否正确,即 和,或者以旧的方式执行此操作更好 - 拥有和私有构造函数||枚举?public interface Signatures
public interface Environments
public final class Signatures
public final class Environments
当我需要一堆无状态实用程序方法时,Java 8中的最佳实践是什么?拥有一个不会由任何人实现的接口是否正确,即 和,或者以旧的方式执行此操作更好 - 拥有和私有构造函数||枚举?public interface Signatures
public interface Environments
public final class Signatures
public final class Environments
接口的主要目的是在该类型上提供操作(方法)的类型和词汇表。它们既有用又灵活,因为它们允许多个实现,实际上它们被设计为允许在类层次结构中不相关的实现。
问题来了,
拥有一个不会被任何人实现的接口是正确的吗??
在我看来,这似乎与接口的粒度相悖。必须环顾 API,以确定没有实现此接口的类,并且没有此接口的生产者或使用者。有人可能会感到困惑,并试图创建接口的实现,但当然他们不会走得太远。虽然可以有一个包含所有静态方法的“实用程序接口”,但这并不像旧的不可构建的最终类习语那样清晰。后者的优点是,该类可以强制不能创建任何实例。
如果您查看新的Java 8 API,您会发现尽管能够在接口上添加静态方法,但仍在使用最终的类习语。
接口上的静态方法已用于工厂方法等创建这些接口的实例,或用于对这些接口的所有实例具有普遍适用性的实用工具方法。例如,请参见 中的 和 接口。每个都有静态工厂:、 和 。Stream
Collector
java.util.stream
Stream.of()
Stream.empty()
Collector.of()
但也要注意,每个都有配套的实用程序类和.这些是纯实用工具类,仅包含静态方法。可以说,它们可以合并到相应的接口中,但这会使接口变得混乱,并会模糊类中包含的方法之间的关系。例如,包含一系列相关的静态方法,这些方法都是 和 之间的适配器。将这些合并到可能会使事情变得混乱。StreamSupport
Collectors
StreamSupport
Spliterator
Stream
Stream
我会使用最后一类。更好地向我传达它是一个具有一些实用程序方法的帮助器类。接口定义是我期望实现的东西,并且存在的方法可以帮助某人实现接口。