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

Why is Java's AbstractList's removeRange() method protected?

提问by Joonas Pulakka

Does anyone have any idea, whyremoveRange method in AbstractList(and also in ArrayList) is protected? It looks like a quite well-defined and useful operation, but still, to use it, we're forced to subclass the List implementation.

有谁知道，为什么AbstractList（以及ArrayList）中的removeRange 方法是protected？它看起来是一个定义明确且有用的操作，但为了使用它，我们仍然不得不继承 List 实现。

Is there some hidden rationale? Seems quite inexplicable to me.

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

采纳答案by Chris Jester-Young

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

是的，因为这不是从外部代码中删除范围的方式。相反，请执行以下操作：

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

This actually calls removeRangebehind the scenes.^?

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

---

---

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

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

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 reducethe method count by increasing orthogonality. For example, consider the java.util.Listinterface. 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 subListmethod, which takes two parameters and returns a viewof a sublist. This method can be combined with the indexOfor lastIndexOfmethods, each of which has a single parameter, to yield the desired functionality. Moreover, the subListmethod can be combined with anymethod that operates on a Listinstance to perform arbitrary computations on sublists. The resulting API has a very high power-to-weight ratio.

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

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

有人可能会争辩说，removeRange它没有那么多参数，因此可能不是这种处理的候选者，但鉴于有一种方法可以removeRange通过调用subList，没有理由List用冗余方法使接口混乱。

---

---

^?The AbstractList.removeRangedocumentation says:

^? 该AbstractList.removeRange文件说：

This method is called by the clearoperation on this list and its subLists. Overriding this method to take advantage of the internals of the list implementation can substantiallyimprove the performance of the clearoperation on this list and its subLists.

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

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

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