Design Patterns

Design Patterns
Iterator / Observer
Artur Pereira Neto
Conteúdo
01. Introdução e Contextualização
02. Histórico de desenvolvimento
03. Formato de um padrão de projeto
04. Categorias de padrão de projeto
05. Padrão ITERATOR
06. Padrão OBSERVER
06. Referências
Introdução e Contextualização
Padrões de Projeto
• PADRÕES DE PROJETO SÃO SOLUÇÕES EM
NÍVEL DE DESIGN PARA PROBLEMAS
RECORRENTES QUE OS ENGENHEIROS DE
SOFTWARE E DESENVOLVEDORES
ENCONTRAM COM FREQUÊNCIA.
• ELES SÃO COMO UMA DESCRIÇÃO DE

COMO LIDAR COM ESSES PROBLEMAS E
PROJETAR UMA SOLUÇÃO.
Padrões de Projeto
• EXISTEM CERCA DE 23 PADRÕES DE
PROJETO IDENTIFICADOS E
DOCUMENTADOS
• ESTES 26 PADRÕES PODEM SER

AGRUPADOS EM 3 CATEGORIAS:
⚬ CRIACIONAIS
⚬ ESTRUTURAIS
⚬ COMPORTAMENTAIS
Padrões de Projeto
• UM PADRÃO ENCERRA O CONHECIMENTO
DE UMA PESSOA MUITO EXPERIENTE EM
UM DETERMINADO ASSUNTO DE UMA
FORMA QUE ESTE CONHECIMENTO PODE
SER TRANSMITIDO PARA OUTRAS
PESSOAS MENOS EXPERIENTES.
Padrões de Projeto
• A IDÉIA DE PADRÕES FOI APRESENTADA POR
CHRISTOPHER ALEXANDER EM 1977 NO CONTEXTO
DE ARQUITETURA (DE PRÉDIOS E CIDADES):
"Cada padrão descreve um problema que ocorre

repetidamente de novo e de novo em nosso ambiente, e
então descreve a parte central da solução para aquele
problema de uma forma que você pode usar esta solução
um milhão de vezes, sem nunca implementa-la duas vezes
da mesma forma."
Vantagens no uso de Padrões de projeto
• Fornecem soluções que já foram testadas e aprovadas.
• Tornam o sistema mais fácil de entender e manter.
• Facilitam o desenvolvimento de módulos coesos.
• A comunicação entre os participantes do projeto fica mais eficiente.

Histórico de desenvolvimento
DesenvolvimentoHistórico
1977
CRISTOPHER
ALEXANDER
O arquiteto e pesquisador
na universidade de
Berkeley. Reconhece e
cunha a terminologia
sobre padrões de design
aplicada a projetos de
arquitetura e urbanismo.
1977 1987
CRISTOPHER CUNNINGHAM E
ALEXANDER
O arquiteto e pesquisador InspiradosBECK
pelas ideias de
na universidade de Christopher Alexander
Berkeley. Reconhece e publicam o livro "Using
cunha a terminologia pattern languages for
sobre padrões de design object-oriented programs
aplicada a projetos de "
1977 1987 1991
CRISTOPHER CUNNINGHAM E ERICH GAMMA

ALEXANDER
pelas ideias de Defende sua tese de
na universidade de Christopher Alexander doutorado em Zurich
Berkeley. Reconhece e publicam o livro "Using sobre bibliotecas para o
cunha a terminologia pattern languages for desenvolvimento
sobre padrões de design object-oriented programs interativo de aplicações
aplicada a projetos de " gráficas
1977 1987 1991 1993
CRISTOPHER CUNNINGHAM E ERICH GAMMA HILLSIDE GROUP

ALEXANDER
pelas ideias de Defende sua tese de Promovem a fusão das
na universidade de Christopher Alexander doutorado em Zurich ideias de Christopher
Berkeley. Reconhece e publicam o livro "Using sobre bibliotecas para o Alexander com as
cunha a terminologia pattern languages for desenvolvimento recentes descobertas de
sobre padrões de design object-oriented programs interativo de aplicações Erich Gamma. Ainda hoje
aplicada a projetos de " gráficas são referência na
arquitetura e urbanismo. disseminação de
informações sobre o
assunto.
1977 1987 1991 1993 1995
CRISTOPHER CUNNINGHAM E ERICH GAMMA HILLSIDE GROUP GOF

ALEXANDER
pelas ideias de Defende sua tese de Promovem a fusão das Erich Gamma, Richard
na universidade de Christopher Alexander doutorado em Zurich ideias de Christopher Helm, Ralf Johnson e
Berkeley. Reconhece e publicam o livro "Using sobre bibliotecas para o Alexander com as John Vlissides lançam o
cunha a terminologia pattern languages for desenvolvimento recentes descobertas de livro "Design patterns:
sobre padrões de design object-oriented programs interativo de aplicações Erich Gamma. Ainda hoje elements of reusable
aplicada a projetos de " gráficas são referência na object oriented software
arquitetura e urbanismo. disseminação de ". Os 4 autores ficam
informações sobre o conhecidos como GoF
assunto. (Gang of four).
1977 1987 1991 1993 1995 1996
CRISTOPHER CUNNINGHAM E ERICH GAMMA HILLSIDE GROUP GOF P.O.S.A

ALEXANDER
pelas ideias de Defende sua tese de Promovem a fusão das Erich Gamma, Richard F. Buschmann, R.
na universidade de Christopher Alexander doutorado em Zurich ideias de Christopher Helm, Ralf Johnson e Meunier, H. Rohnert, P.
Berkeley. Reconhece e publicam o livro "Using sobre bibliotecas para o Alexander com as John Vlissides lançam o Sommerlad e M. Stal of
cunha a terminologia pattern languages for desenvolvimento recentes descobertas de livro "Design patterns: publicam o livro "Pattern
sobre padrões de design object-oriented programs interativo de aplicações Erich Gamma. Ainda hoje elements of reusable oriented software
aplicada a projetos de " gráficas são referência na object oriented software Architecture" focando
arquitetura e urbanismo. disseminação de ". Os 4 autores ficam na aplicação de padrões
informações sobre o conhecidos como GoF na solução de problemas
assunto. (Gang of four). de grande escala
GoF Padrões de projeto
• Passa-se a ter um vocabulário comum para conversar sobre projetos de software.
• Soluções passam a ter nome característico.
• Ao invés de discutirmos um sistema em termos de pilhas, filas, árvores e listas

encadeadas, passa-se a tartar de conceitos de mais alto nível.
• A maioria dos autores eram entusiastas de Smalltalk, principalmente o Ralph

Johnson.Mas acabaram baseando o livro em C++ para que o impacto junto à
comunidade de CC fosse maior.
E. Gamma and R. Helm and R. Johnson and J. Vlissides.
Design Patterns - Elements of Reusable Object-Oriented
Software. Addison-Wesley, 1995.
Formato de um padrão
Segundo GoF
Formato de um padrão segundo GoF
• Nome
⚬ Transmite a essencia do padrão de forma sucinta. Uma boa escolha do nome é
essencial.
• Objetivo / Intenção
⚬ Uma declaração curta que responde Às perguntas: o que o padrão faz, qual seu
objetivo, qual questão particular é abordada pelo padrão.
• Também Conhecido Como
⚬ Eventuais outros nomes para o padrão
• Motivação
⚬ Um cenário que ilustra um problema de design e como as classes e objetos do
padrão resolvem o problema.
Formato de um padrão segundo GoF
• Aplicabilidade
⚬ Em quais situações o padrão é aplicável
• Estrutura
⚬ Uma representação gráfica da estrutura de classes do padrão (usando object
modelling technique OMT91)
• Participantes
⚬ As classes e objetos que participam e quais são suas responsabilidades
• Colaborações
⚬ Como os participantes colaboram para exercer as suas responsabilidades
Categorias dos
Padrões de Projeto
Categorias dos padrões de projeto
Creational Patterns
(Padrões criacionais)
• Padrões criacionais (Creational Patterns) abstraem o

porocesso de instanciação de objetos.
• Sistemas tornam-se independentes de como os

objetos são criados, construídos e representados.
• Padrões criacionais tornam-se relevantes à medida

que sistemas começam a se tronar mais
dependentes da criação de objetos do que do
processo de herança de classes.
Structural Patterns
(Padrões estruturais)
• Os padrões estruturais explicam como montar

objetos e classes em estruturas maiores mas ainda
mantendo essas estruturas flexíveis e eficientes.
• As classes usam herança para criar interfaces ou

implementações. Objetos podem ter sua
composição alterada em run-time.
Behavioural Patterns
(Padrões comportamentais)
• Padrões comportamentais são voltados aos algoritmos e a
designação de responsabilidades entre objetos.
• Define também o padrão de comunicação entre estruturas
(classes e objetos)
O padrão de projeto
ITERATOR
Formato do padrão ITERATOR
• Nome
⚬ Iterator
⚬ O Iterator é um padrão de projeto
comportamental que permite a você percorrer
elementos de uma coleção sem expor as
representações dele (lista, pilha, árvore, etc.)
Fonte: https://refactoring.guru/pt-br/design-patterns/iterator
⚬ Cursor
• Motivação
⚬ Coleções são um dos tipos de dados mais usados em programação. Não obstante,
uma coleção é apenas um contêiner para um grupo de objetos.
⚬ A maioria das coleções armazena seus elementos em listas simples. Contudo, alguns
deles são baseados em pilhas, árvores, grafos, e outras estruturas complexas de
dados.Mas independente de quão complexa uma coleção é estruturada, ela deve
fornecer uma maneira de acessar seus elementos para que outro código possa usá-
los. Deve haver uma maneira de ir de elemento em elemento na coleção sem ter que
acessar os mesmos elementos repetidamente.
• Motivação
⚬ Se a coleção é baseada numa lista basta fazer um loop em todos os elementos.
⚬ Mas como proceder em uma estrutura de dados complexa, tal como uma árvore? Um
dia pode ser necessário percorrer em profundidade, no dia seguinte na amplitude, na
semana seguinte um acesso aleatório aos elementos da árvore.
Formato de um padrão ITERATOR
• Aplicabilidade
⚬ Em quais situações o padrão é aplicável
• Estrutura
⚬ Uma representação gráfica da estrutura de classes do padrão (usando object
modelling technique OMT91)
• Participantes
⚬ As classes e objetos que participam e quais são suas responsabilidades
• Colaborações
⚬ Como os participantes colaboram para exercer as suas responsabilidades
• Solução proposta
⚬ A ideia principal do padrão Iterator é extrair o
comportamento de travessia de uma coleção
para um objeto separado chamado um
iterador.
⚬ Além de implementar o algoritmo em si, um

objeto iterador encapsula todos os detalhes da
travessia, tais como a posição atual e quantos
elementos faltam para chegar ao fim. Por
causa disso, alguns iteradores podem
averiguar a mesma coleção ao mesmo tempo,
independentemente um do outro.
⚬ Os iteradores fornecem um método primário
para pegar elementos de uma coleção. O
cliente pode manter esse método funcionando
até que ele não retorne mais nada, o que
significa que o iterador atravessou todos os
elementos.
⚬ Todos os iteradores devem implementar a

mesma interface. Isso faz que o código cliente
seja compatível com qualquer tipo de coleção
ou qualquer algoritmo de travessia desde que
haja um iterador apropriado.
⚬ Se for necessário uma maneira especial para a

travessia de uma coleção, basta criar uma
nova classe iterador, sem ter que mudar a
coleção ou o cliente.
• Estrutura
• Estrutura
• Estrutura
• Estrutura
• Estrutura
• Estrutura
• Estrutura
Aplicabilidade do padrão ITERATOR
• Utilize o padrão Iterator quando sua coleção tiver uma estrutura de dados complexa por debaixo dos panos,
mas você quer esconder a complexidade dela de seus clientes (seja por motivos de conveniência ou segurança).
O iterador encapsula os detalhes de se trabalhar com uma estrutura de dados complexa, fornecendo ao
cliente vários métodos simples para acessar os elementos da coleção.
Embora essa abordagem seja muito conveniente para o cliente, ela também protege a coleção de ações
descuidadas ou maliciosas que o cliente poderia fazer se estivesse trabalhando com as coleções
diretamente.
• Utilize o padrão para reduzir a duplicação de código de travessia em sua aplicação.
O código de algoritmos de iteração não triviais tendem a ser muito pesados.
Quando colocados dentro da lógica de negócio da aplicação, ele pode desfocar a responsabilidade do
codigo original e torná-lo um código de difícil manutenção.
Mover o código de travessia para os iteradores designados pode ajudar você a tornar o código da
aplicação mais enxuto e limpo.
• Utilize o Iterator quando você quer que seu código seja capaz de percorrer diferentes estruturas de dados ou
quando os tipos dessas estruturas são desconhecidos de antemão.
O padrão fornece um par de interfaces genérica tanto para coleções como para iteradores.
Já que o código usa essas interfaces, ele ainda vai funcionar se você passar diversos tipos de coleções e
iteradores que implementam essas interfaces.
O padrão de projeto
OBSERVER
Formato do padrão OBSERVER
• Nome
⚬ Observer
⚬ O Observer é um padrão de projeto comportamental
que permite a definição de um mecanismo de
assinatura para notificar múltiplos objetos sobre
quaisquer eventos que aconteçam com o objeto que
eles estão observando. https://refactoring.guru/pt-br/design-patterns/observer

⚬ ssinante do evento, Event-Subscriber, PubSub, Listener
Formato do padrão OBSERVER
• Motivação
⚬ Suponha que existam dois tipos de objetos: um Cliente e uma Loja. O cliente está
muito interessado em uma marca particular de um produto (digamos que seja
um novo modelo de iPhone) que logo deverá estar disponível na loja.
⚬ O cliente pode visitar a loja todos os dias e checar a disponibilidade do produto.
Mas enquanto o produto ainda está a caminho, a maioria desses visitas serão
em vão.
⚬ Por outro lado, a loja poderia mandar milhares de emails (que poderiam ser
considerados como spam) para todos os clientes cada vez que um novo produto
se torna disponível. Isso salvaria alguns clientes de incontáveis viagens até a
loja. Porém, ao mesmo tempo, irritaria outros clientes que não estão
interessados em novos produtos.
⚬ Parece que temos um conflito. Ou o cliente gasta tempo verificando a
disponibilidade do produto ou a loja gasta recursos notificando os clientes
errados.
Formato de um padrão OBSERVER
⚬ O padrão Observer sugere que seja adicionado
um mecanismo de assinatura para a classe
publicadora para que objetos individuais
possam assinar ou desassinar uma corrente
de eventos vindo daquela publicadora.
⚬ Esse mecanismo consiste em:

￭ 1) um vetor para armazenar uma lista de
referências aos objetos do assinante
￭ 2) alguns métodos públicos que permitem https://refactoring.guru/pt-br/design-patterns/observer
adicionar assinantes e removê-los da lista.
⚬ Aplicações reais podem ter dúzias de diferentes
classes assinantes que estão interessadas em
acompanhar eventos da mesma classe
publicadora.
⚬ Não é interessante acoplar a publicadora a todas
essas classes.
⚬ Por isso que é crucial que todos os assinantes
implementem a mesma interface e que a
publicadora comunique-se com eles apenas
através daquela interface. Essa interface deve
declarar o método de notificação junto com um https://refactoring.guru/pt-br/design-patterns/observer
conjunto de parâmetros que a publicadora pode

usar para passar alguns dados contextuais junto
com a notificação.
• Estrutura
https://refactoring.guru/pt-br/design-patterns/observer
• Estrutura
• Estrutura
• Estrutura
• Estrutura
• Estrutura
• Estrutura
Aplicabilidade do padrão OBSERVER
• Utilize o padrão Observer quando mudanças no estado de um objeto podem precisar mudar outros objetos, e o
atual conjunto de objetos é desconhecido de antemão ou muda dinamicamente.
O padrão Observer permite que qualquer objeto que implemente a interface do assinante possa se
inscrever para notificações de eventos em objetos da publicadora.
• Utilize o padrão quando alguns objetos em sua aplicação devem observar outros, mas apenas por um tempo
limitado ou em casos específicos.
A lista de inscrição é dinâmica, então assinantes podem entrar e sair da lista sempre que quiserem.
Referências
Referências
• Freeman, E., Bates, B., Freeman, E., Robson, E., Sierra, K. (2004). Head First Design
Patterns. Alemanha: O'Reilly Media, Incorporated.
• Gamma, E. (2000). Padrões de Projetos: Soluções Reutilizáveis. Brasil: Bookman.
• https://refactoring.guru/pt-br

Design Patterns

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Design Patterns

Enviado por

Direitos autorais:

Formatos disponíveis

Design Patterns

02. Histórico de desenvolvimento

03. Formato de um padrão de projeto

04. Categorias de padrão de projeto

05. Padrão ITERATOR

06. Padrão OBSERVER

• ELES SÃO COMO UMA DESCRIÇÃO DE

• ESTES 26 PADRÕES PODEM SER

"Cada padrão descreve um problema que ocorre

• Fornecem soluções que já foram testadas e aprovadas.

• Tornam o sistema mais fácil de entender e manter.

• Facilitam o desenvolvimento de módulos coesos.

• A comunicação entre os participantes do projeto fica mais eficiente.

CRISTOPHER CUNNINGHAM E ERICH GAMMA

CRISTOPHER CUNNINGHAM E ERICH GAMMA HILLSIDE GROUP

CRISTOPHER CUNNINGHAM E ERICH GAMMA HILLSIDE GROUP GOF

CRISTOPHER CUNNINGHAM E ERICH GAMMA HILLSIDE GROUP GOF P.O.S.A

• Passa-se a ter um vocabulário comum para conversar sobre projetos de software.

• Soluções passam a ter nome característico.

• Ao invés de discutirmos um sistema em termos de pilhas, filas, árvores e listas

• A maioria dos autores eram entusiastas de Smalltalk, principalmente o Ralph

• Padrões criacionais (Creational Patterns) abstraem o

• Sistemas tornam-se independentes de como os

• Padrões criacionais tornam-se relevantes à medida

• Os padrões estruturais explicam como montar

• As classes usam herança para criar interfaces ou

⚬ Além de implementar o algoritmo em si, um

⚬ Todos os iteradores devem implementar a

⚬ Se for necessário uma maneira especial para a

O código de algoritmos de iteração não triviais tendem a ser muito pesados.

• Também Conhecido Como

⚬ Esse mecanismo consiste em:

conjunto de parâmetros que a publicadora pode

• Gamma, E. (2000). Padrões de Projetos: Soluções Reutilizáveis. Brasil: Bookman.

Você também pode gostar