E

TEMA : PATRON DE DISEÑO ITETATOR

CURSO : TOPICOS ESPECIALESEN INGENIERIA DE SOFTWARE

CICLO :

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

ContenidoDEDICATORIA........................................................................................................................... i

INTRODUCCION....................................................................................................................... iv

MARCO TEORICO.....................................................................................................................v

CAPITULO I: ALGUNOS ASPECTOS GENERALES DEL PATRON ITERATOR................7

1.1. Definición................................................................................................................7

1.2. Objetivo...................................................................................................................8

1.3. Motivacion...............................................................................................................8

1.4 Estructura.............................................................................................................10

1.4.1. Particiones.....................................................................................................10

CAPITULO II : APLICACIÓN DEL PATRON ITERATOR....................................................11

2.1. Aplicabilidad.........................................................................................................11

2.2. Colaboraciones......................................................................................................11

2.3. Consecuencias.......................................................................................................11

2.4. Implementaciones………………………………………………………………………………………………12

2.5. Usos Conocidos……………………………………………………………………………….…….……………12

2.6. Ventajas e Inconvenientes…………………………………………………………………………….…..13

CONCLUSIONES.....................................................................................................................13

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

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

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

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.

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 los elementos 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.

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:

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.

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 Iterator para devolver la instancia de IteratorConcreto apropiada.

CAPITULO II: APLICACIÓN DEL PATRON ITERATOR

1.5. 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)

1.6. Colaboraciones

Un ConcreteIterator mantiene la pista de cuáles fueron los objetos que se recorrieron y conoce el elemento siguiente al actual.

1.7. 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.

1.8. 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

1.9. 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.

1.10. Ventajas e Inconvenientes

Permite variaciones en el recorrido del agregado encapsulando los algoritmos de recorrido 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

Definamos la interfaz Aggregate

Definamos el ConcreteAggregate y el ConcreteIterator

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.