通用集合 [英] Generic Collection

问题描述

这是Java（1.6）Collection接口的一部分：

  public interface Collection< E>扩展java.lang.Iterable< E> {
 / * ... * / 
 boolean containsAll（java.util.Collection<> objects）; 
 boolean addAll（java.util.Collection< ;? extends E> es）; 
 boolean removeAll（java.util.Collection<？> objects）; 
 boolean retainAll（java.util.Collection<？> objects）; 
 / * ... * / 
} 
  

为什么 addAll 有<？在 removeAll 具有<？>

$ b时，扩展E> $ b

解决方案

我不知道，我用Google搜索了一下。我在这里得到了这个解释： http://www.ibm.com/developerworks/java/ library / j-jtp01255 / index.html

复制零件：

开始经常令人困惑的基因化集合API的一个元素是containsAll（），removeAll（）和retainAll（）的签名。您可能会认为remove（）和removeAll（）的签名是：

  interface Collection< E> {
 public boolean remove（E e）; //不是真的
 public void removeAll（Collection< ;? extends E> c）; //不是
} 
  

但事实上：

 界面集合< E> {
 public boolean remove（Object o）; 
 public void removeAll（Collection <？>> c）; 
} 
  

这是为什么？同样，答案在于向后兼容性。 x.remove（o）的接口契约是指如果o包含在x中，则删除它;否则不做任何事情。如果x是泛型集合，则o不必与x的类型参数类型兼容。如果removeAll（）被泛化为只有在其参数类型兼容时才可调用（ Collection <？extends E> ），那么在泛型之前合法的某些代码序列会变成非法的，就像这样：

  //一个整数集合
 Collection c = new HashSet（）; 
 //一个对象集合
 Collection r = new HashSet（）; 
 c.removeAll（r）; 
  

如果上述片段以显而易见的方式被基因化（使ca Collection <整数> 和ra Collection< Object> ），那么如果removeAll（）的签名需要它的参数是一个收集和LT ;?扩展E> ，而不是无操作。生成类库的关键目标之一是不破坏或改变现有代码的语义，所以remove（），removeAll（），retainAll（）和containsAll（）必须用弱类型约束来定义。可能有他们从头开始重新设计的泛型。

This is part of the Java (1.6) Collection interface:

public interface Collection<E> extends java.lang.Iterable<E> { 
    /* ... */   
    boolean containsAll(java.util.Collection<?> objects);    
    boolean addAll(java.util.Collection<? extends E> es);    
    boolean removeAll(java.util.Collection<?> objects);    
    boolean retainAll(java.util.Collection<?> objects);
    /* ... */   
}

Why does addAll have <? extends E> while removeAll has <?>

解决方案

I did not know, I googled. I got this explaination here: http://www.ibm.com/developerworks/java/library/j-jtp01255/index.html

Copying the part:

One element of the generifed Collections API that is often confusing at first is the signatures of containsAll(), removeAll(), and retainAll(). You might expect the signatures for remove() and removeAll() to be:

interface Collection<E> { 
  public boolean remove(E e);  // not really
  public void removeAll(Collection<? extends E> c);  // not really
}

But it is in fact:

interface Collection<E> { 
  public boolean remove(Object o);  
  public void removeAll(Collection<?> c);
}

Why is this? Again, the answer lies in backward compatibility. The interface contract of x.remove(o) means "if o is contained in x, remove it; otherwise, do nothing." If x is a generic collection, o does not have to be type-compatible with the type parameter of x. If removeAll() were generified to only be callable if its argument was type-compatible (Collection<? extends E>), then certain sequences of code that were legal before generics would become illegal, like this one:

// a collection of Integers
Collection c = new HashSet();
// a collection of Objects
Collection r = new HashSet();
c.removeAll(r);

If the above fragment were generified in the obvious way (making c a Collection<Integer> and r a Collection<Object>), then the code above would not compile if the signature of removeAll() required its argument to be a Collection<? extends E>, instead of being a no-op. One of the key goals of generifying the class libraries was to not break or change the semantics of existing code, so remove(), removeAll(), retainAll(), and containsAll() had to be defined with a weaker type constraint than they might have had they been redesigned from scratch for generics.

这篇关于通用集合的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！