java - 拆分器 getExactSizeIfKnown 与 estimateSize

Question

这是在我编写 custom 时出现的Spliterator。我知道estimateSize如果我知道大小，甚至是近似值，我应该覆盖。通常，我会这样做。但是有getExactSizeIfKnown，我知道它是默认实现：

default long getExactSizeIfKnown() {
    return (characteristics() & SIZED) == 0 ? -1L : estimateSize();
}

现在，假设我正在研究一个ArrayListSpliterator（我知道它已经存在，这不是重点）。我应该覆盖getExactSizeIfKnown还是estimateSize两者兼而有之？

在内部，我猜getExactSizeIfKnown实际上是被调用的，而不是 estimateSize- 因为第一个委托给第二个。考虑到理论上我正在研究一个ArrayListSpliterator，实际上不会覆盖getExactSizeIfKnown只是让我支付一个额外的方法调用 - 绕道getExactSizeIfKnown- > estimateSize？

Answer 1

“我应该覆盖getExactSizeIfKnown还是estimateSize两者兼而有之？”的答案 是，您必须estimateSize按原样实施abstract。如果您看到原因，您可以另外覆盖该default方法。getExactSizeIfKnown

在内部，我猜getExactSizeIfKnown实际上是被调用的，而不是 estimateSize- 因为第一个委托给第二个。

没那么简单。为代码调用做好准备，getExactSizeIfKnown因为它可能仅在准确且未检查特征的情况下使用该数字。但同时可能有其他代码调用estimateSize，要么是因为它想要一个估计，要么是因为它会在另一个地方处理特征。一个default实现可以在特定条件下委托给另一个实现这一事实并没有说明调用者的任何内容。这些方法具有不同的语义。

考虑到理论上我正在研究一个ArrayListSpliterator，实际上不会覆盖getExactSizeIfKnown只是让我支付一个额外的方法调用 - 绕道getExactSizeIfKnown- > estimateSize？

条件可能比委托调用更有害，但是如果您的特定Spliterator对象总是返回相同的特征，则 JVM 的优化器可能会消除与此相关的任何开销。因此，这是通常的权衡，在这里，与微小的开发工作相比，潜在的性能优势很小（用于提供仅返回已知数字的附加方法）。

如果大小的计算不是微不足道的，那么无论如何您最终都会委托，因为您不希望重复非平凡的代码。如果你的类的设计方式SIZED并不总是存在特征，那么无论如何你都会做与方法完全相同的事情default。