Iterator

Provee un mecanismo estándar para acceder secuencialmente a los elementos de una colección; define una interface que declara métodos para acceder secuencialmente a los objetos de una colección. Una clase accede a una colección a través de dicha interface.

La motivación de este patrón reside en la gran diversidad de colecciones y algoritmos que existe hoy en día para recorrer una colección. Lo que se busca es acceder a los contenidos de los objetos incluidos sin exponer su estructura.
Podemos decir que este patrón nace para poder soportar diversas formas de recorrer objetos y para ofrecer una interfaz uniforme para recorrer distintos tipos de estructuras de agregación.

Se utiliza cuando:

• Una clase necesita acceder al contenido de una colección sin llegar a ser dependiente de la clase que es utilizada para implementar la colección, es decir sin tener que exponer su representación interna.
• Una clase necesita un modo uniforme de acceder al contenido de varias colecciones.
• Cuando se necesita soportar múltiples recorridos de una colección.

Este patrón debe ser utilizado cuando se requiera una forma estándar de recorrer una colección, es decir, cuando no es necesario que un cliente sepa la estructura interna de una clase. Un cliente no siempre necesita saber si debe recorrer un List o un Set o un Queue y, menos que menos, que clase concreta esta recorriendo.
El ejemplo más importante de este patrón esta en el Java Framework Collection: las colecciones en el paquete java.util siguen el patrón Iterator. La causa de porque Java utiliza este patrón es muy simple. En la versión 1.6 Java posee alrededor de 50 colecciones. Y cada una de ellas es un caso de estudio: cada una funciona de manera distinta a la otra, con algoritmos muy distintos, por ejemplo: hay trees, binary trees, arrays, ring buffers, hashes, hash maps, array lists, sets, etc. Si nosotros como clientes de Java tendríamos que aprender como se debe recorrer una colección en Java, sería realmente muy molesto. Pero si todas las colecciones se recorren de la misma forma estándar, y además, cada colección sabe cual es la mejor manera de recorrerla, entonces sería un gran avance que, de hecho, lo es.

Diagrama UML




Agregado/Aggregate: define una interfaz para crear un objeto iterator.
Iterator: define la interfaz para acceder y recorrer los elementos de un agregado.
IteradorConcreto: implementa la interfaz del iterador y guarda la posición actual del recorrido en cada momento.
AgregadoConcreto: implementa la interfaz de creación de iteradores devolviendo una instancia del iterador concreto apropiado.

Cliente: solicita recorrer una colección y lo hace siguiendo los métodos otorgados por la interfaz Iterator.

Ejemplo

Vamos a realizar un ejemplo muy sencillo: una división o sucursal que contiene empleados. Para ello internamente implemento un Array pero el cliente no tiene porque saberlo.

 
 Y ahora crearemos un Iterator para recorrer los empleados de la división. El método iterator devuelve un objeto DivisionIterator. Veamos como funciona:

Si ha recorrido alguna colección mediante un objeto Iterator estará familiarizado con el siguiente código:

Consecuencias

• Es posible acceder a una colección de objetos sin conocer el código de los objetos.
• Utilizando varios objetos Iterator, es simple tener y manejar varios recorridos al mismo tiempo.
• Es posible para una clase Colecction proporcionar diferentes tipos de objetos Iterator que recorran la colección en diferentes modos. Por ejemplo, una clase Colecction que mantiene una asociación entre la clave de los objetos y el valor de los objetos podría tener diferentes métodos para crear Iterators que recorran sólo la clave de los objetos y crear Iterators que recorran sólo el valor de los objetos.
• Las clases Iterator simplifican el código de las colecciones, ya que el código de los recorridos se encuentra en los Iterators y no en las colecciones.