Este documento describe el patrón de diseño Iterator. El patrón Iterator proporciona una interfaz para acceder secuencialmente a los elementos de un agregado sin exponer su representación interna. El patrón separa la responsabilidad de iterar sobre un agregado en un objeto separado llamado iterador, permitiendo diferentes formas de recorrer el agregado y múltiples recorridos simultáneos.

1. E
TEMA
CURSO
CICLO
:
PATRON DE DISEÑOITETATOR
: TOPICOS ESPECIALESEN INGENIERIA DE
SOFTWARE
:
VI
PROFESOR
:
Ing. José Arturo Díaz Pulido
INTEGRANTES :
- Cabrera Linares, José
- De la Cruz Mantilla, Azucena
- Santillán Huallán, Daniel
TRUJILLO-PERU 2014

2. Contenido
DEDICATORIA ........................................................................................................................... 7
INTRODUCCION ...................................................................................................................... 10
MARCO TEORICO .................................................................................................................... 11
CAPITULO I:ALGUNOS ASPECTOS GENERALES DEL PATRON ITERATOR ............... 11
1.1.
Definición ............................................................................................................... 11
1.2.
Objetivo ......................................................................Error! Bookmark not defined.
1.3.
Motivacion................................................................................................................ 8
1.4
Estructura ..................................................................Error! Bookmark not defined.
1.4.1.
Particiones ................................................................Error! Bookmark not defined.0
CAPITULO II: APLICACIÓN DEL PATRON ITERATOR ................................................... 151
2.1.
Aplicabilidad ............................................................Error! Bookmark not defined.1
2.2.
Colaboraciones ........................................................Error! Bookmark not defined.1
2.3.
Consecuencias ............................................................Error! Bookmark not defined.
2.4.
Implementaciones………………………………………………………………………………………………12
2.5. Usos Conocidos……………………………………………………………………………….…….……………12
2.6.Ventajas e Inconvenientes…………………………………………………………………………….…..13
CONCLUSIONES ...................................................................................................................... 13

3. DEDICATORIA
La presente proyecto monográfico se la dedico
a mi familia que a sus consejos y palabras de aliento
crecí como persona. Gracias por ayudarme a cumplir
mis objetivos como persona y estudiante.
AZUCENA

4. DEDICATORIA
A Dios Todopoderoso por darme
las fuerzas y el ímpetu para seguir
adelante a pesar de las adversidades.
A mis padres por su amor,
ayuda y apoyo en todo momento.
Gracias por esta hermosa herencia.
DANIEL

5. DEDICATORIA
La presente proyecto monográfico
se la dedico a mi familia que a sus consejos
y palabras de aliento crecí como persona.
Gracias por ayudarme a cumplir mis
objetivos como persona y estudiante.
JOSE

6. INTRODUCCION
El patrón de diseño de comportamiento Iterator presenta la interfaz que declara los métodos
necesarios para acceder, de forma secuencial, a los objetos de una colección.
El iterator cubre la necesidad de acceder a los elementos de un contenedor de objetos sin tener
que trabajar con su estructura interna, facilitando de este modo el acceso a la información.
Además, es posible que se necesite más de una forma de recorrer la estructura siendo para ello
necesario crear modificaciones en la clase.
Por otro lado los iteradores no tienen por qué limitarse a recorrer la estructura, sino que podrían
incorporar otro tipo de lógica (por ejemplo, filtrado de elementos). Es más, dados diferentes
tipos de estructuras, el patrón iterator permite recorrerlas todas utilizando una interfaz común
uniforme.
Mediante el uso del patrón, se añaden métodos que permiten recorrerla sin referenciar su
representación, por lo que la responsabilidad del recorrido se traslada a un objeto que sea capaz
de iterar.
La gran desventaja de que usar este objeto que itere, más o menos encapsulado, es que muchas
veces se necesita conocer la estructura del contenedor para elegir del tipo iterator más adecuado.
Esto se soluciona abstrayendo los tipos de los distintos iteradores y dotando a las estructuras de
un método que cree un iterador concreto.
El patrón Iterator permite por tanto diferentes tipos de recorrido de un agregado y varios
recorridos simultáneos, simplificando la interfaz del agregado.

7. MARCO TEORICO
CAPITULO I: ALGUNOS ASPECTOS GENERALES DEL
PATRON ITERATOR
1.1.
Definición
Proporciona un modo de acceder secuencialmente a los elementos de un objeto
agregado sin exponer su representación interna. El patrón de diseño Iterator tiene como
finalidad proveer un camino para acceder a los elementos de una colección secuencial de
objetos sin exponer la representación interna de dicho recorrido.
Una colección de objetos, tal como una lista deberían proveer una forma o camino de
acceso a sus elementos sin exponer su representación interna.
Por otra parte, se podría necesitar también recorrer la lista de diferentes formas,
dependiendo del problema al que se le deba dar solución. Pero probablemente no se quiera
llenar la “interface Lista” con operaciones que recorran sus elementos en distintas
direcciones. También se podría tener más de un recorrido pendiente por recorrer en la misma
lista.
El patrón Iterator permite resolver los problemas anteriormente planteados. La idea
principal de este patrón es tomar la responsabilidad de acceso y recorrido de los objetos de
una lista, agregando a esta última un objeto de tipo Iterator.
La clase iterator define una interface que permite acceder a los elementos de una lista.
Un Objeto de tipo Iterator es el encargado de ir guardando el recorrido del elemento
corriente, es decir, conoce los elementos que ya se han recorrido.
Por ejemplo, una clase List necesitaría una clase ListIterator con la siguiente relación entre
ellas.
Antes de instanciar la clase ListIterator se deberá proporcionar la lista de loselementos a
recorrer. Una vez instanciada la clase ListIterator, se podrá tener acceso a los elementos de
List, secuencialmente. La operación CurrentItem() (Item corriente), retorna el elemento
corriente de la lista. Firts() inicializa el elemento corriente con el primer elemento de la lista,
Next() avanza el elemento corriente a siguiente elemento de la lista y la operación IsDone()
chequea que no se haya avanzado más allá del último elemento, es decir, chequea que el
recorrido no haya finalizado.
Separando los mecanismos de recorrido de los objetos de la clase List permitirá definir
iteradores con diferentes políticas de recorrido, sin enumerarlos dentro de la interface List.
Por ejemplo la operación FilteringListIterator permitirá el acceso sólo a aquellos
elementos de la lista que cumplan alguna restricción que actuará como filtro.
Es importante notar que la lista y el iterador están asociados, y que el cliente debe
conocer que esta lista podrá ser recorrida de forma diferente a otras colecciones de objetos.

8. Además el cliente debe optar por un tipo de objetos en particular. Sería mucho mejor si
se pudiera cambiar el tipo de los elementos de la lista sin necesidad de cambiar el código del
cliente que la utiliza. Esto puede lograrse generalizando el concepto de iterador de manera tal
que pueda soportar iteraciones polimórficas. Está ultima es una de las principales ventajas de
utilizar el patrón de diseño Iterator
Como ejemplo, supongamos que tenemos una implementación especial de lista llamada
SkipList. Estas listas especiales son estructuras de datos probabilísticas con características
similares a los árboles balanceados. Por lo tanto deberemos definir un iterador que funcione
para ambos tipos de listas.
1.2.
OBJETIVO
Proporcionar acceso secuencial a los elementos de un agregado, sin exponer su
representación interna.
1.3.
MOTIVACION
Un objetivo agregado, como por ejemplo una lista, debería darnos una forma de acceder
a sus elementos sin exponer su estructura interna. Más aun, tal vez queramos recorrer la lista
de diferentes formas, dependiendo de lo que queramos realizar. Pero probablemente no
querremos plagar la interfaz de lista con operaciones para diferentes recorridos, incluso en el
caso de que pudiéramos prever cuales se van a necesitar. Por otro lado, también puede
necesitarse hacer más de un recorrido simultáneamente sobre la misma lista.
El patrón iterator nos permite hacer todo esto. La idea clave de este patrón es tomar la
responsabilidad de acceder y recorrer el objeto lista y poner dicha responsabilidad en un
objeto iterator. La clase iterator define una interfaz para acceder a los elementos de la lista.
Un objeto iterator es el responsable de saber cuál es el elemento actual; es decir, sabe que
elementos ya han sido recorridos.
Por ejemplo, una clase lista pediría un IteradorLista con la siguiente relación entre ambos:

9. Antes de que pueda crearse una instancia de IteratorLista debemos proporcionarle la
lista a recorrer. Una vez que tenemos la instancia de IteradorLista, podemos acceder
secuencialmente a los elementos de la lista. La operación ElementoActual devuelve el
elemento actual de la lista; Primero inicializa el elemento actual al primer elemento;
Siguiente hace avanzar el elemento actual al siguiente elemento; y HaTerminado
comprueba si se ha avanzado más allá del último elemento, es decir, si se ha finalizado el
recorrido.
Separar el mecanismo de recorrido del objeto Lista nos permite definir iteradores con
diferentes políticas de recorrido sin necesidad de enumerarlos en la interfaz Lista. Por
ejemplo, IteradorListaConFiltro podría proporcionar acceso solo a aquellos que satisfagan
las normas del filtrado.
Nótese que el iterator y la lista están acoplados, y que el cliente debe saber que lo que se
está recorriendo es una lista y no otra estructura agregada. Por tanto, el cliente se ajusta a una
determinada estructura agregada. Sería mejor que pudiésemos cambiar la clase agregada sin
saber el código cliente. Podemos hacer esto por generalización del concepto de iterator para
permitir la interacción polimórfica.
Como ejemplo, supongamos que ya tenemos una implementación de una lista
ListaConSaltos. Una lista con saltos (skiplist) es una estructura de datos con características
similares a los arboles equilibrados. Nos gustaría poder escribir código que funcionase tanto
para objetos Lista como para objetos ListaConSaltos.
Definimos una clase ListaAbstracta que proporciona una interfaz común para manipular
listas. Igualmente, necesitamos una clase abstracta iterator que defina una interfaz de
interación común. Entonces podemos definir las subclases concretas de Iterator para las
diferentes implementaciones de listas. Como resultado, el mecanismo de iteración se vuelve
independiente de las clases agregadas concretas.

10. Nos queda el problema de cómo crear el iterador. Puesto que queremos escribir código
que sea independiente de las subclases concretas de Lista, no podemos crear simplemente
una instancia de una clase determinada. En vez de eso, haremos que los objetos lista sean
responsables de crear sus correspondientes iteradores. Esto requiere una operación como
CrearIterator, mediante la cual los clientes soliciten un objeto iterador.
1.4.
Estructura
1.4.1.
Particiones
Iterator:
- Define interfaz para acceder y recorrer elementos
IteradorConcreto:
- Implementa la interfaz Iterator
- Mantiene la posición actual en el recorrido del agregado
Agregado:
- Define interfaz para crear un objeto Iterator
AgregadoConcreto:
- Implementa una interfaz de creación del Iteratorpara devolver la instancia de
IteratorConcretoapropiada.

11. CAPITULO II: APLICACIÓN DEL PATRON ITERATOR
2.1.
Aplicabilidad
El problema siguiente es cómo crear un iterador. Para ello se debe escribir el código sin
tener en cuenta el tipo específico de los elementos de la lista a recorrer motivo por el cual
no se podrá instanciar una lista de un tipo particular. Como solución a esto se propone que
los objetos de la lista tomen la responsabilidad de crear sus propios iteradores. Esto
requiere una operación adicional, llamada CreateIterator() a través de la cual el cliente
pueda solicitar un objeto iterador.
Es conveniente utilizar el patrón Iterador en las siguientes situaciones:
Para acceder al contenido de un agregado sin exponer su representación interna
Para permitir varios recorridos sobre un agregado Para proporcionar una interfaz
uniforme
para recorrer distintos tipos de agregados (esto es, permitir iteración polimórfica)
2.2.
Colaboraciones
Un ConcreteIterator mantiene la pista de cuáles fueron los objetos que se recorrieron
y conoce el elemento siguiente al actual.
2.3.
Consecuencias
Este patrón tiene tres consecuencias importantes:
Soporta variaciones en el recorrido de una colección, puesto que estructuras
complejas pueden requerir recorridos en muchas formas. Los iteradores hacen
fácil cambiar el algoritmo de recorrido, con sólo reemplazar la instancia del
iterador a una diferente.
Los iteradores simplifican la interfaz de las colecciones, ya que la interfaz de
los recorridos se encuentra en los iteradores y no en la clase que corresponde a
la estructura en cuestión.
Más de un recorrido puede estar pendiente en una colección, puesto que cada
iterador mantiene la pista de su recorrido. Por lo tanto, se puede tener más de un
recorrido en progreso al mismo tiempo.

12. 2.4.
Implementaciones
Los iteradores tienen muchas variantes y alternativas en cuanto a la implementación.
Las ventajas dependen de las estructuras de control que el lenguaje provea. Algunas de
las más importantes son las siguientes:
• ¿Quién controla la iteración?
La iteración puede ser controlada de forma interna (controlada por el iterador), o de
forma externa (controlada por el cliente).
• ¿Quién define el algoritmo de recorrido?
El algoritmo puede ser definido dentro de la colección, con lo cual el iterador es
utilizado sólo como cursor de la posición actual o en la clase Iterator
• Operaciones adicionales en el iterador
-
Se pueden adicionar operaciones a las ya básicas (First, Next, IsDone y
CurrentItem)
•Iteradores para tipos compuestos (Composite)
•Iteradores nulos
2.5.
Usos Conocidos
Los iteradores son frecuentes en los sistemas orientados a objetos. La mayoría de las
bibliotecas de clases ofrecen iteratores de una u otra.
El siguiente ejemplo de los componentes de Booch, una popular biblioteca de clases de
colecciones. Proporciona dos implementaciones de una cola, una para un tamaño fijo y
otra que pueda crecer dinámicamente. La interfaz de la cola la define una clase abstracta
Queue. Para permitir iterar polimórficamente sobre las diferentes implementaciones de
colas, el iterador de la cola se complementa en términos de la interfaz e la clase
abstracta Queue. Esta variación tiene la ventaja de que no se necesita un método de
fabricación para pedirle a las implementaciones de colas su iterator apropiado. No
obstante, en necesario que la interfaz de la clase abstracta Queue sea lo bastante potente
como para implementarla de manera eficiente el iterator.
En Smalltalk no hay que definir explícitamente los iteradores. Las clases de colecciones
estándar Bag, Set, Dictionary, OrderedCollection, string, etc. Definen un método do:
como un iterator interno el cual toma un bloque (es decir, un cierre) como parámetro.
Cada parámetro de la colección se liga a la variable local del bloque; a continuación se
ejecuta el bloque. Smalltalk también incluye un conjunto de clases Stream que permiten
un interfaz similar a un iterador. ReadStream es básicamente un iterador, y puede actuar
como un iterador extremo para todas las colecciones secuenciales. No hay iteradores
externos estándar para las colecciones no secuenciales como Set y Dictionary.

13. 2.6.
Ventajas e Inconvenientes
Permite variaciones en el recorrido del agregado encapsulando los algoritmos
derecorrido en distintas subclases de iteradores.
Simplifica la interfaz del agregado al no incluir las operaciones de iteración
Permite recorridos simultáneos con varios iteradores a la vez.
CAPITULO III: EJEMPLO DEL PATRON DE DISEÑO
Veremos un pequeño ejemplo en código, en primer lugar definimos un objeto de dominio
básico: este ejemplo trata de ingresar en un vector de tipo (int) la cual deseamos saber cuáles
son pares e impares. Una forma sencilla de hacer esto ya lo sabemos el cual expone su
estructura interna al cliente.
Lo que el patrón Iterador propone es crear una clase que realice recorridos independientemente
de la clase que manipula los valores de la estructura.
Definamos el interfaz Iterator

14. Definamos la interfaz Aggregate
Definamos el ConcreteAggregate y el ConcreteIterator

16. CONCLUSIONES
Es conveniente usar este patrón cuando una clase necesita accesar el contenido de una
colección, sin hacerse dependiente de la clase que implementa la colección.
Permite variaciones en el recorrido de un agregado
Los iteradores simplifican la interfaz de los agregados ya que el recorrido de los mismos
se define en una interfaz separada.
Se puede hacer más de un recorrido a la vez sobre un mismo agregado ya que cada
iterador mantiene el estado de su propio recorrido.
BIBLIOGRAFIA
1. Erich Gamma (2003). Patrones de diseño.
2. Carlos Bermejo (2005). Patrones de diseño de software.
3. David Chávez López (2006). Patrones de diseño en Java.
4. Eduardo Mosqueira Rey (2006) .Patrones de Diseño.