iterador de Java sobre una colección vacía de un tipo parametrizado

Question

En Java, necesito devolver un iterador de mi método. Mis datos provienen de otro objeto que generalmente me puede dar un iterador, así que puedo devolverlo, pero en algunas circunstancias los datos subyacentes son nulos. Por coherencia, quiero devolver un iterador "vacío" en ese caso para que las personas que llaman no tengan que probar nulo.

que quería escribir algo como:

public Iterator<Foo> iterator() { 
    if (underlyingData != null) { 
     return underlyingData.iterator(); // works 
    } else { 
     return Collections.emptyList().iterator(); // compiler error 
    } 
} 

Pero el compilador de Java se queja de la Iterator<Object> en lugar de regresar Iterator<Foo>. Casting a (Iterator<Foo>) tampoco funciona.

Answer 1

, usted puede obtener una lista vacía de tipo Foo través de la siguiente sintaxis:

return Collections.<Foo>emptyList().iterator(); 

Answer 2

Lo sentimos, lo he descubierto. Necesita usar una asignación para que el compilador pueda descifrar el tipo parametrizado.

public Iterator<Foo> iterator() { 
    if (underlyingData != null) { 
     return underlyingData.iterator(); 
    } else { 
     List<Foo> empty = Collections.emptyList(); // param type inference 
     return empty.iterator(); 
    } 
} 

Answer 3

me gustaría ir más a lo largo de las líneas de

public Iterator<Foo> iterator() { 
    if (underlyingData == null) 
     return Collections.<Foo> emptyList().iterator(); 
    return underlyingData.iterator(); 
} 

Así, manejar el caso especial y devolución, y luego manejar el caso normal. Pero mi punto principal es que se puede evitar la asignación con

Collections.<Foo> emptyList().iterator(); 

Answer 4

supongo que esto demuestra que la inferencia de tipos de Java no funciona en todos los casos y que el operador ternario no siempre es equivalente al parecer equivalentes si-else construir.

También quiero indicar evitar null. También evite pasar Iterator s, porque tienen un comportamiento de estado extraño (prefiera Iterable). Sin embargo, suponiendo que tiene una razón legítima, no prematuro para hacer esto, mi forma preferida de escribir sería

public Iterator<Foo> iterator() { 
    return getUnderlyingData().iterator(); 
} 
private List<Foo> getUnderlyingData() { 
    if (underlyingData == null) { 
     return Collections.emptyList(); 
    } else { 
     return underlyingData; 
    } 
} 

OMI, es mejor no introducir la información de tipo inferirse si se puede inferir (incluso si hace que tu código sea más largo).

Seguramente va a hacerlo más de una vez, por lo tanto, inserte un método getUnderlyingData en lugar de simplemente declarar una variable local.

Está llamando al iterator en ambos resultados, así que no se repita.

Answer 5

La molestia de Collections.<Foo>emptyList().iterator() es la razón principal por la que proporcionamos Iterators.emptyIterator() en google-collections. No se necesita ningún parámetro de tipo, en casos como el tuyo.

Answer 6

public final class EmptyIterator{ 

    public static Iterator iterator(){ 
     return new Empty(); 
    } 

    private static class Empty implements Iterator { 
     public boolean hasNext(){ 
      return false; 
     } 
     public Object next(){ 
      throw new NoSuchElementException(); 
     } 
     public void remove(){ 
     } 
    } 
} 

Answer 7

Java 7 ha estado fuera por mucho tiempo. A menos que esté desarrollando para una versión anterior de Java, devolvería un iterador vacío como este:

return Collections.emptyIterator();