Design Patterns com Delphi - Iterator - Parte I

Trabalhar com estruturas de dados organizadas em coleções como listas, mapas e filas, entre outras, é situação extremamente comum para quem programa computadores. De tão corriqueira, muitas linguagens de programação incorporaram em suas bibliotecas mecanismos genéricos para proporcionar a navegação pelos elementos adicionados a uma coleção. É o caso da plataforma .NET e do Java - ambos possuem interfaces com esse objetivo que têm o nome de Iterator – e também do C++, onde esse recurso é uma das funcionalidades incluídas como um template da STL.

O tipo de navegação descrito acima também é abordado por um dos Design Patterns comportamentais mais utilizados, chamado justamente de Iterator. A ideia dele é permitir que se percorra os elementos de uma coleção sem que seja necessário conhecimento prévio do tipo de estrutura de dados que está armazenada na coleção nem o método de organização da coleção. Esta abstração, portanto, dá ao programador a possibilidade de criar uma infraestrutura genérica para tratar certas situações num sistema. Uma vez pronta e testada a infraestrutura, agregar novas funcionalidades a ela passaria a ser tarefa bem mais simples, implementando-se apenas novas classes periféricas.

Como exemplo de uma infraestrutura assim, imagine a construção de uma tela genérica que é capaz de exibir linhas numa tabela. Cada linha desenhada na tabela corresponde a um registro retornado por uma coleção qualquer, sendo que a origem dos dados dessa coleção pode ser uma consulta ao banco de dados, uma lista de registros selecionados na mão pelo usuário, etc. A ordem com que os registros devem ser listados é inerente à própria coleção, livrando a tela de ter que conhecer de antemão essa ordem. Uma representação dessa proposta usando o pattern Iterator é retratada no quadro abaixo.

Formalmente, a nomenclatura para as classes integrantes dessa solução é a seguinte.

O Iterator é uma classe abstrata que estabelece o formato das funções para percorrer os itens da coleção, permitindo acesso aos itens individuais armazenados numa coleção, independentemente do tipo de dado real. Essa classe, portanto, fornece uma abstração para o acesso ordenado aos dados contidos na coleção. No diagrama de exemplo acima, esse é o papel da classe TWIterator.
São classificados como ConcreteIterator as classes que implementam as funções estabelecidas pelo Iterator , providenciando os mecanismos reais de acesso típico de cada estrutura de dados - listas, pilhas, filas, recordsets do banco de dados, etc. Como cada ConcreteIterator conhece a forma com que os dados são organizados numa coleção, eles servem de ponte para que outras classes possam ter acesso aos dados através de uma interface comum (representada pelo próprio Iterator). Há 3 classes desse tipo no diagrama de exemplo: TWItMovtosPorData, TWItClientes e TWItCarrinho.
O Aggregate é uma classe abstrata que define a interface para a criação do Iterator associado a uma coleção. Com isso, partes do programa que utilizem coleções podem instanciar corretamente o Iterator necessário para percorrer os itens da coleção, sem precisar se preocupar com a estrutura da coleção nem com o tipo de dado armazenado. No nosso exemplo, a interface é definida pela classe TWCollection.
Os ConcreteAggregate são classes que providenciam a criação do ConcreteIterator apropriado à coleção que cada um deles representa. Veja, portanto, que cada ConcreteIterator está intimamente ligado a ao menos um ConcreteAggregate, conhecendo-lhe sua estrutura e organização. Por isso, nosso exemplo também tem 3 classes do tipo ConcreteAggregate : TWColMovtosEstoque, TWColClientes e TWColCarrinhoCompras.
Por fim, qualquer classe que consuma uma coleção (Aggregate) e um Iterator são tidas como Clients. É esse o caso da classe TWBrowseForm incluída no diagrama do exemplo.

No próximo post eu mostro como codificar as classes envolvidas no exemplo apresentado aqui.

Mais Informações
Posts sobre Design Patterns