Design Patterns - Aula 2

Prof.ª Esp. Talita Pagani [email protected] | @talitapagani

Especialização em Engenharia de Software

22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 1

1. Definição de Design Patterns

2. Design Patterns para softwares orientados a objetos

a. Padrões de criação;

b. Padrões estruturais;

c. Padrões comportamentais;

3. Estudo de caso de Design Patterns;

4. Modelagem de software com auxílio de Design Patterns

5. Design Patterns para interfaces gráficas;

6. Design Patterns para mobile.


Informações gerais

• Cria uma instância de várias famílias de classes.

• Quando e onde usar: – Para criar famílias de objetos

relacionados ou dependentes;

– Quando é necessário isolar classes concretas de suas superclasses;

– Quando um sistema precisa de independência de como seus produtos são criados, compostos e representados.

Padrões de criação


Fonte: GAMMA, et al., 2007; MCDONALD, 2007;

JAVACAMP, 2012, DOFACTORY, 2014.

• Separa a construção de um objeto complexo de sua representação.

• Quando e onde usar: – Quando for necessário criar um

objeto complexo, especificando apenas seu tipo e conteúdo. O objeto construído está protegido dos detalhes de sua construção;

– Quando se deseja dissociar o processo de construção de um objeto complexo a partir das partes que compõem o objeto;

– Quando é necessário isolar o código para a construção e representação.





• Cria uma instância de várias classes derivadas.

• Quando e onde usar: – Quando uma classe quer que

suas subclasses especifiquem o objeto;

– Quando uma classe não pode antecipar suas subclasses;

– Quando uma família de objetos precisa ser separada utilizando uma interface comum;

– Para esconder classes concretas;

– Para parametrização na criação de objetos.





• Uma instância completa a ser copiada ou clonada.

• Quando e onde usar: – Quando há muitas subclasses que

diferem apenas no tipo de objetos;

– Quando um sistema precisa de independência de como seus produtos são criados, compostos e representados;

– Quando é necessário adicionar ou remover objetos em tempo de execução;

– Quando é necessário especificar novos objetos, alterando a estrutura, ou configurando uma aplicação com classes dinâmicas.





• Garante que uma classe tenha somente uma instância e fornece um ponto global de acesso para ela.

• Quando e onde usar: – Quando é necessário criar

uma instância única, definindo uma classe final;

– Ao desejar controlar a instanciação de uma classe com um valor compartilhado por todas as instâncias.





• Casa interfaces de diferentes classes.

• Quando e onde usar: – Ao necessitar de

delegação de objetos;

– Quando é necessário fazer com que classes não relacionadas trabalhem juntas.


Padrões estruturais



• Separa a interface de um objeto de sua implementação.

• Quando e onde usar: – Quando se quer separar a

abstração da implementação de forma permanente;

– Quando se quer melhorar a extensibilidade;

– Quando se deseja ocultar detalhes de implementação.





• Uma estrutura em árvore de objetos simples e consistentes.

• Quando e onde usar: – Quando se deseja agrupar

componentes para formar componentes maiores que, por sua vez, podem ser agrupados para formar componentes ainda maiores.





• Adiciona responsabilidades a um objeto dinamicamente.

• Quando e onde usar: – Quando é necessário

adicionar uma nova função para um objeto sem afetar outros objetos.





• Uma classe que representa todo um subsistema.

• Quando e onde usar: – Em sistemas complexos,

quando se deseja reduzir a complexidade;

– Quando é necessário minimizar a comunicação e a dependência entre subsistemas.





• Uma instância granularizada usada para compartilhamento eficiente.

• Quando e onde usar: – Quando é preciso instanciar

uma grande quantidade de classes pequenas e granuladas;

– Quando é necessário ícones para representar objetos;

– Para ter um estado de objeto extrínseco, que pode ser compartilhado entre classes.





• Um objeto que representa outro objeto.

• Quando e onde usar: – Se a criação do objeto é muito

custosa em tempo e memória;

– Se é necessário adiar a criação do objeto até que você precise do mesmo;

– Quando é necessário realizar operações que consomem tempo, como carregar uma imagem grande;

– Quando é necessário permissões de acesso para um sistema complexo.





• Uma forma de passar uma requisição entre uma cadeia de objetos.

• Quando e onde usar: – Quando uma requisição

deve ser tratada por mais de um objeto;

– Quando não é possível saber qual objeto deve lidar com a requisição.


Padrões comportamentais



• Encapsula a requisição de um comando como um objeto.

• Quando e onde usar: – Quando uma ação pode ser

representada de várias formas;

– Quando há necessidade de desfazer uma ação, armazenando seus estados para mais tarde recuperá-los.





• Inclui elementos de linguagem em um programa.

• Quando e onde usar: – Quando é necessário o

seu próprio gerador de interpretador;

– Para traduzir uma expressão específica;

– Ao tratar uma informação em árvore.





• Acessa sequencialmente os elementos de uma coleção.


distinguir variações transversais de um aggregate;

– Quando é necessário filtrar alguma informação de uma coleção de agregação.





• Define uma comunicação simplificada entre classes.


particionar um sistema em pequenos objetos;

– Quando é necessário limitar subclasses;

– Quando a relação entre a classe de controle e outras classes participantes é multidirecional.





• Captura e restaura o estado interno de um objeto.


funções de desfazer e refazer;

– Use para gerenciar transações de banco de dados.





• Notifica uma alteração a um determinado número de classes.

• Quando e onde usar: – Quando uma mudança afeta

um ou mais objetos;

– Quando o comportamento de muitos objetos depende de um ou mais estados;

– Quando é necessário comunicação em broadcast.





• Altera o comportamento de um objeto quando seu estado é alterado.


controlar muitos estados sem o uso de declarações if-else ou switch;

– Quando cada estado deve agir de forma semelhante e deve ser uma subclasse de uma mesma superclass.





• Encapsula um algoritmo dentro de uma classe.

• Quando e onde usar: – Quando é preciso

encapsular vários algoritmos para desempenhar funções semelhantes, mas estes algoritmos são permutáveis e variam de forma independente;

– Use para reduzir instruções condicionais.





• Define as etapas exatas de um algoritmo a uma subclasse.

• Quando e onde usar: – Para fazer template de

operações similares;

– Quando é necessário passar de muitas operações especializadas para uma operação genérica.





• Define uma nova operação a uma classe sem alterá-la.


adicionar operações a várias classes que possuem interfaces diferentes.





Criacionais • Foco: criação de objetos complexos

• Esconde como objetos complexos são criados

Estruturais

• Foco: compor objetos para formar estruturas robustas

• Cria novas funcionalidades a partir de funcionalidades

antigas

• Provê flexibilidade e extensibilidade

Comportamentais

• Foco: algoritmos e atribuição de responsabilidades a

objetos

• Evita acoplamento forte a uma solução em particular


Design Patterns para softwares orientados a objetos

• Proxy: pode ser de 3 tipos

– Remote proxy

• Cache de informação

– Virtual Proxy

• Para objetos que consomem tempo e tamanho

– Protection Proxy

• Controle de acesso



• Abstract Factory para um jogo




Game

Match

TTTMatch ChessMatch

Chess TicTacToe

createMatch() createStats()

Statistics

TTTStats ChessStats

Tournament

createMatch() createStatistics()

createMatch() createStats()

Se no documento de requisitos constar... Significa...

“independente de dispositivo”

“deve suportar uma família de produtos”

Abstract Factory

“deve se comunicar com objetos

existentes”

Adapter

“deve se comunicar com diversos

sistemas, sendo que alguns serão

desenvolvidos futuramente”

“um protótipo inicial deve ser

demonstrado”

Bridge

“deve se comunicar com um conjunto

existente de objetos”

Façade



Se no documento de requisitos constar... Significa...

“estrutura complexa”

“deve variar em profundidade e largura”

Composite

“deve ser transparente quanto à

localização do acesso”

Proxy

“deve ser extensível e/ou escalável” Observer

“deve prover uma política de

funcionamento independente do

mecanismo”

Strategy



• Encapsulamento

• Generalista

• Abstração

• Equilíbrio

• Abertura

• Combinatoriedade



Estudo de caso


• Sistema de colaboração entre componentes (AMMAR, 2008) – Rastrear os estados

de três componentes colegas e manter os seus estados idênticos.


Estudo de caso


Estudo de caso

Figura 1 - Diagrama de Classe antes de aplicar o padrão.

Fonte: AMMAR, 2008.


Estudo de caso

Figura 3 - A estruturação das classes utilizando o padrão Mediator.

Fonte: AMMAR, 2008.


Estudo de caso

Figura 4 – Comunicação entre as classes com o Mediator.

Fonte: AMMAR, 2008.


Estudo de caso

Figura 2 - Diagrama de Classe depois de aplicar o Mediator.

Fonte: AMMAR, 2008.

• O padrão Mediator reduz a

dependência entre os componentes

e aumenta a reusabilidade,

extensibilidade e manutenibilidade

da arquitetura do software.


Estudo de caso

Estudo de caso


• A estrutura ideal de um subsistema consiste

de:

– Uma interface;

– Um conjunto de objetos de domínio do

aplicativo (entidades) para modelar entidades

reais ou sistemas existentes;

– Um ou mais objetos de controle;


Estudo de caso

• Realização do objeto Interface: Façade

– Provê uma interface de acesso ao subsistema

• Interface ao sistema existente: Adapter ou Bridge

– Provê a interface para os sistemas legados

– Os sistemas existentes não precisam ser necessariamente orientados a objetos


Estudo de caso

• Façade – Deve ser oferecido por todos os sistemas em um sistema

como um serviço

• Adapter – Deve ser utilizado como uma interface para os componentes

existentes

• Bridge – Deve ser utilizado como uma interface para um conjunto de

objetos, quando o conjunto completo de objetos não é completamente conhecido


Estudo de caso

• Similaridades – Ambos são utilizados para esconder detalhes de

implementação.

• Diferenças – Adapter: para objetos que geralmente não trabalham

juntos • Herança seguida de delegação

– Bridge: para deixar as abstrações e implementações variarem independentemente • Delegação seguida de herança


Estudo de caso


Estudo de caso

Herança

Delegação Delegação

• Selecionando padrões:

– Considere como padrões de projeto solucionam

problemas de projeto;

– Examine as seções de Intenção;

– Estude como os padrões se interrelacionam;

– Estude padrões de finalidades semelhantes;

– Examine uma causa de reformulação de projeto ou

considere o que deveria ser variável no seu projeto.


Laboratório 1

• Imagine uma situação onde você precisa implementar um balanceador de carga para gerenciar conexão com servidores.

• Apenas uma única instância da classe pode ser criada, pois os servidores podem ficar online e offline dinamicamente e cada requisição deve passar por um objeto que tenha conhecimento da web farm.


Laboratório 1

• Solução: Singleton

– Uma única operação de instanciação;

– Criar e dar manutenção a esta única instância.

• Exemplo de código: p. 21 da apostila


Laboratório 1

• Você está desenvolvendo um plugin de comentários para páginas de um sistema gerenciador de conteúdo (CMS).

• Este plugin deve enviar um e-mail quando um comentário é adicionado, sendo que o mailer é uma função intrínseca do CMS.

• Dessa forma, ao adicionar um comentário, o Mailer deve estar ciente de que deve enviar um e-mail para o autor da página.


Laboratório 1

• Solução: Observer

– Comportamento em que a alteração do estado

de um objeto afeta outro;

– Modificar o Mailer para que ele seja uma classe

observadora.

• Exemplo de código: p. 24 da apostila


Laboratório 1


Laboratório 1

• Formar grupos de 4 a 5 pessoas

• Duas situações para identificar os padrões

• Esboçar um diagrama no Astah Community

• 45min para cada situação apresentada

• Para cada situação, definir: Qual o pattern que poderia ser utilizado?


Laboratório 1

• Você está desenvolvendo uma aplicação para agilizar a

criação de documentos usando modelos pré-definidos, que

atualmente suporta dois tipos: Relatórios e Currículos.

• A ferramenta precisa ser flexível para a criação destes

documentos. Embora eles tenham propriedades em comum

(ambos têm páginas), um Relatório deve conter tipos de

páginas para introdução, resultados, conclusão, sumário e

bibliografia, enquanto que um currículo possui páginas de

habilidades, formação e experiência profissional.

• Ao criar um Relatório ou um Currículo, ele já deve produzir

(retornar) estas páginas padrões.


Laboratório 1

• Em um dado sistema de e-commerce, os produtos

podem ser classificados em categorias pré-

determinadas, que compõem o menu de

navegação do site, e em tags, que são

classificações atribuídas pelos consumidores.

• Ambas conectam com o mesmo banco de dados e

precisam ser retornadas da mesma forma, sendo

selecionadas do banco de dados e listadas na tela.


Laboratório 1

• Nesta atividade, você deverá selecionar uma

situação vivenciada no seu cotidiano de

trabalho onde você já implementou ou poderia

implementar ao menos um design pattern.

Descreva qual o problema resolvido (ou que

poderia ser resolvido) e porque aquele(s)

pattern(s) foi(foram) escolhidos (ou poderiam

ser escolhidos) para resolver esta situação.


Tarefas

• Cada grupo, de 4 a 5 pessoas, deverá montar um conjunto de, no mínimo, 5 patterns identificados através de situações vivenciadas no cotidiano de trabalho. Os patterns identificados podem ser diversos: algoritmos, soluções de interface ou processos.

• O importante é que eles sejam válidos como uma solução de sucesso utilizada para resolver um problema recorrente.


Tarefas

• ALEXANDER, C., et al. A Pattern Language. Oxford University Press, 1977.

• AMMAR, H. H. 2008. Case Studies on Design Patterns. Disponível em: http://www.csee.wvu.edu/~ammar/rts/adv rts/design patterns

case studies/before and after CaseStudies.ppt

• BRUEGGE, B.; DUTOIT, A. H. 2014. Object-Oriented Software Engineering. Disponível em:

http://www.cs.bilkent.edu.tr/~ugur/teaching/cs319/

• DOFACTORY. 2014. .NET Design Patterns. Disponível em: http://www.dofactory.com/Patterns/Patterns.aspx

• GAMMA, E., et al. Padrões de projeto: soluções reutilizáveis de software orientado a objetos; tradução de Luiz A. Meirelles Salgado.

Porto Alegre: Bookman, 2007.

• HEGODA, D. 2013. Why? When to? Software Design Patterns. Disponível em: http://dasunhegoda.com/software-design-

patterns/158/

• JAVACAMP. 2012. Java Design Patterns At a Glance. Disponível em: http://www.javacamp.org/designPattern/

• LEACOCK, M.; MALONE, E.; WHEELER, C. Implementing a Pattern Library in the Real World: A Yahoo! Case Study. In: Sixth Annual

ASIS&T Information Architecture Summit. Montréal, Quebec, Canada, mar. 2005. Disponível em: http://leacock.com/patterns/

• MCDONALD, J. 2007. Design Patterns Quick Reference. Disponível em: http://www.mcdonaldland.info/2007/11/28/40/

• MEMÓRIA, F. Design para a internet: Projetando a experiência perfeita. Rio de Janeiro: Elsevier, 2005.

• VINICIUS, G. 2011. Padrões de design orientado a objetos. Disponível em: http://pt.slideshare.net/glaucovinicius/padres-de-design-

orientado-a-objetos

• WELIE, M. V. 2008. Patterns in Interaction Design. Disponível em: http://www.welie.com/patterns/


http://www.csee.wvu.edu/~ammar/rts/adv rts/design patterns case studies/before and after CaseStudies.ppt







http://www.dofactory.com/Patterns/Patterns.aspx

http://dasunhegoda.com/software-design-patterns/158/





http://www.javacamp.org/designPattern/

http://leacock.com/patterns/

http://www.mcdonaldland.info/2007/11/28/40/

http://pt.slideshare.net/glaucovinicius/padres-de-design-orientado-a-objetos












http://www.welie.com/patterns/

Design Patterns - Aula 2

Technology

Transcript of Design Patterns - Aula 2