为什么Java的AbstractList的removeRange()方法受到保护？

发布于 2024-08-21 15:15:05 字数 356 浏览 9 评论 0原文

有谁知道为什么的removeRange方法“noreferrer">AbstractList（也在 ArrayList) 是否受保护？它看起来是一个定义良好且有用的操作，但为了使用它，我们不得不对 List 实现进行子类化。

难道有什么隐藏的道理吗？对我来说似乎很莫名其妙。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

潇烟暮雨 2024-08-28 15:15:05

是的，因为这不是从外部代码中删除范围的方式。相反，这样做：

list.subList(start, end).clear();

这实际上在幕后调用 removeRange。^†

OP 询问为什么 removeRange 不是 List< 的一部分/code> 公共 API。原因在Effective Java 2nd ed的Item 40中有描述，我在这里引用一下：

可以使用三种技术来缩短过长的参数列表。一种是将方法分解为多个方法，每个方法仅需要参数的子集。如果不小心，这可能会导致方法过多，但它也可以通过增加正交性来帮助减少方法计数。例如，考虑 java.util.List 接口。它不提供查找子列表中元素的第一个或最后一个索引的方法，这两者都需要三个参数。相反，它提供了 subList 方法，该方法采用两个参数并返回子列表的视图。此方法可以与 indexOf 或 lastIndexOf 方法结合使用，每个方法都有一个参数，以产生所需的功能。此外，subList 方法可以与List 实例上操作的任何方法组合，以对子列表执行任意计算。由此产生的 API 具有非常高的功率重量比。

有人可能会说 removeRange 没有那么多参数，因此可能不适合这种处理，但考虑到有一种方法可以通过 removeRange 调用 removeRange >subList，没有理由用冗余的方法使 List 接口变得混乱。

^† AbstractList.removeRange 文档说：

此方法由对此列表及其子列表的clear 操作调用。重写此方法以利用列表实现的内部结构可以显着提高对此列表及其子列表进行clear操作的性能。

另请参阅 OpenJDK 的 AbstractList.clear 和 SubList.removeRange。

Yes, because that's not how you remove a range from outside code. Instead, do this:

list.subList(start, end).clear();

This actually calls removeRange behind the scenes.^†

The OP asks why removeRange is not part of the List public API. The reason is described in Item 40 of Effective Java 2nd ed, and I quote it here:

There are three techniques for shortening overly long parameter lists. One is to break the method up into multiple methods, each of which requires only a subset of the parameters. If done carelessly, this can lead to too many methods, but it can also help reduce the method count by increasing orthogonality. For example, consider the java.util.List interface. It does not provide methods to find the first or last index of an element in a sublist, both of which would require three parameters. Instead it provides the subList method, which takes two parameters and returns a view of a sublist. This method can be combined with the indexOf or lastIndexOf methods, each of which has a single parameter, to yield the desired functionality. Moreover, the subList method can be combined with any method that operates on a List instance to perform arbitrary computations on sublists. The resulting API has a very high power-to-weight ratio.

One can argue that removeRange doesn't have that many parameters and is therefore probably not a candidate for this treatment, but given that there's a way to invoke removeRange through the subList, there is no reason to clutter up the List interface with a redundant method.

^† The AbstractList.removeRange documentation says:

This method is called by the clear operation on this list and its subLists. Overriding this method to take advantage of the internals of the list implementation can substantially improve the performance of the clear operation on this list and its subLists.

Also, see OpenJDK's implementation of AbstractList.clear and SubList.removeRange.

回复收藏 0 原文

~没有更多了~