java - 为什么 List.remove 会像现在这样重载？

Question

这两个模棱两可有历史原因吗List.remove ？

• List.remove(int)
• List.remove(Object)

我觉得这设计很糟糕。
对于 List<Integer>看起来真的很困惑。

编辑:

似乎每个人都对此很满意。让我说清楚一点。

假设我有一个 List<Boolean> .

Integer idx = Integer.valueOf(2);
list.remove(idx)

虽然idx是一个对象，Java 编译并将删除索引 2 处的项目。

现在如果它是 List<Integer> ，完全相同的代码会调用具有完全不同行为的不同方法。

我们先不谈泛型会发生什么。

我觉得不同的行为意味着不同的名字是一个宝贵的规则，尤其是在同一个类(class)中。

Answer 1

首先:

• List.remove(int)删除指定索引处的元素 和
• List.remove(Object) (或 Collection.remove(Object) )删除指定的元素。

我不确定这是否已经为人所知，但为了完整起见，我想我会提到它。

需要注意的一个重要部分是 API 比泛型(更重要的是)自动装箱早了很多(集合 API 是在 Java 1.2 中引入的，而自动装箱是在 Java 5 中引入的)。

所以他们在最开始设计API的时候，是绝对没有办法把两者搞混的。即使您的 List 包含 Integer 对象，这也很简单:如果您使用原始参数类型 (int) 调用该方法，那么它就是索引，如果您传入一个 Object(即使它是 Integer)，那么您传入要删除的对象。

诚然，它仍然不是最伟大的想法(但相当多的 Java API ……还不够完美)，但那时出现混淆的可能性要低得多。

由于自动装箱和自动拆箱，int/Integer 屏障变得不那么明显，因此增加了混淆的可能性。

旁注:集合 API 的一个重要“特性”是“常用方法的短名称”。 Vector的前一个“解决方案”/Enumeration非常常见的操作的名称非常长:

• Vector.elementAt() 与 List.get()
• Vector.addElement() 与 Collection.add()
• Enumeration.hasMoreElements()/nextElement() 对比 Iterator.hasNext()/next()
• Vector.removeElement() 与 Collection.remove()
• Vector.removeElementAt() 与 List.remove(int)

最后一个是他们可能做得有点过头的地方。