Separar el mecanismo de recorrido del objeto List nos permite definir iteradores para diferentes políticas de recorrido sin tener que enumerarlas en la interfaz de List.
Cabe notar que el iterador y la lista están acoplados, y el cliente debe saber que es una lista lo que se está recorriendo, en lugar de algún otra estructura agregada. De ahí que el cliente comprometa una estructura agregada particular. Sería mejor si se pudira cambiar la clase agregada sin cambiar el código cliente. Esto se logra generalizando el concepto de iterador para soportar iteración polimorfa.
Se define una clase AbstractList que provea una interfaz común para manipular listas. De igual forma, necesitamos una clase abstracta Iterator que defina una interfaz de iteración común. Luego podemos definir subclasses iteradoras concretas para las diferentes implementaciones de la lista. Como resultado, el mecanismo de iteración llega a ser independiente de las clases agregadas concretas.
El problema restante radica en cómo crear el iterador. Como se quiere es escribir código independiente de las subclasses concretas de List, no se puede instanciar una clase específica. En su lugar, hay q hacer a los objetos de la lista responsables por la creación de su iterador correspondiente. Esto requiere una operación tal como CreateIterator, por medio de la cual los clientes solicitan un objeto iterador.
- Iterator:
- ConcreteIterator:
- Aggregate:
- ConcreteAggregate:
- http://agamenon.uniandes.edu.co/~pfiguero/soo/PatronesDiseno/Iterator/Iterator.html
- DesIgn Patterns: Elements of Reusable Object-Oriented Software Gamma, Helm, Johnson, Vlissides Editorial Addison-Wesley.
No hay comentarios:
Publicar un comentario