Embed Size (px)
Citation preview
ASWI4 – Arquitetura de Software
Joice [email protected]
Samuel Martins (Samuka)[email protected]
Aula 04bDesign Patterns I
1
2
Você está aprendendo pintura.Já sabe misturar as cores,conhece diferentes pincéis, telas, tipos de tinta, etc...
Você sabe tudo o que precisa para pintar um quadro.
Adianta ter este conhecimento,se você não souber comoutilizá-lo?
Oi,
eu sou o
Goku!
3
O mesmo vale paraOrientação a Objetos
Saber como usarHerança, Polimorfismo, ...,
não é suficiente
Em quais situações elesdevem ser empregados?
Existem muitas aplicações diferentescom características/problemas semelhantes
4
Existem muitas aplicações diferentescom características/problemas semelhantes
Logo, temos soluções semelhantes para eles
5
Existem muitas aplicações diferentescom características/problemas semelhantes
Logo, temos soluções semelhantes para eles
6
7
8
A gente define isso depois...Vamos a um exemplo,
porque é bem mais legal =D
Prob01: Duck Hunt Game
99
Prob01: Duck Hunt Game
1010
11
Prob01: Duck Hunt Game
1212
13
Princípio de Design
“Identifique os aspectos de sua aplicaçãoque variam e separe-os dos que se
mantém o mesmo”
14
Princípio de DesignEm outras palavras...
“Pegue o que varia e encapsule,então, isto não afetará o resto de seu
código”
Com isso, conseguimos alterar/extender as partes que variam, sem afetar as que não variam...
15
Sabemos que a parte que varia é o método fly().
Que tal representarmos este comportamento em uma interface, deixando suas implementações a cargo de algumas classes separadas?
Duck Hunter Game
16
17
Duck Hunter Game
Prob01: Duck Hunt Game
18
Step 04E se os Patos pudessem quaquarejar?
O Pato-real faz Quack...O Marreco faz Cocorocó...O Pato de Borracha faz Biurl...
18
19
Princípio de Design
“Programe para uma interface,não para uma implementação”
Princípio de Design
→ Use uma interface para representar cada comportamento, algoritmo, ação que varia.
→ Implemente os comportamento em classes concretas, cujo único objetivo de “viver” é a implementação de tal comportamento.
→ As classes que contém os comportamentos não precisam conhecer nenhum detalhe de implementação dos mesmos.
20
Princípio de Design
→ As classes que contém os comportamentos não precisam conhecer nenhum detalhe de implementação dos mesmos.
→ Elas estão delegando seu comportamento para a interface
→ Elas também não estão presas a uma implementação específica
→ O comportamento do objeto pode ser alterado em execução do programa
21
22
"Programar para uma interface,na verdade significa
programar para um supertipo"
Programa para uma Interface/Supertipo
→ Você não precisa, necessariamente, usar uma Java Interface
→ A ideia é explorar o poliformismo programando para um supertipo → Para que o objeto, em tempo de execução, não fique preso a uma implementação específica
→ O supertipo pode ser representado por uma Interface ou Classe Abstrata
23
// Programar para uma ImplementaçãoProfReservation profRes = new ProfReservation();profRes.makeReservation();
// Programar para uma InterfaceReservation res = new ProfReservation();res.makeReservation();
24
Classe Abstrata ou Interface?
Classe Abstrata:→ Quando a abstração for um conceito (algo que precisa ser refinado ou especializado)
Interface:→ Quando a abstração for um comportamento (algo que uma classe deve saber fazer)
25
Classe Abstrata ou Interface?
Imagine um jogo no qual existem naves que se movem.
Se sua abstração representa uma nave, então você está representando um conceito e deve utilizar uma classe abstrata.
26
Classe Abstrata ou Interface?
Imagine um jogo no qual existem naves que se movem.
Mas, se sua abstração representa algo que se move, então o que está sendo abstraído é um comportamento e a melhor solução é usar uma interface.
27
28
Princípio de Design
“Prefira Composição em vez de Herança”
Princípio de Design→ Em vez de herdar o comportamento, estamos compondo-o
→ A Composição nos dá maior flexibilidade
→ Conseguimos encapsular uma família de comportamentos, algoritmos, ações, ...
→ O comportamento pode ser mudado em tempo de execução
→ Tudo isso facilita a manutenção futura do código
29
30
“Muito prazer, eu sou o Strategy!”
Strategy→ Define uma família de algoritmos (comportamentos), encapsula cada um, e os faz intercambiáveis (de fácil mudança).
31
StrategyDesvantagem:→ Aumento do número de classes
→ Complexidade na criação do Objeto→ Devemos garantir que todos os comportamentos foram atribuídos
32
33
Design Patterns→ Soluções para determinados problemas em determinados contextos.
→ Descreve soluções bem estabelecidas
→ Não basta ser uma solução recorrente→ Precisa ser uma boa solução
34
Design PatternsA ideia vem do trabalho do arquiteto Christopher Alexander
35
Design PatternsIniciou-se em OO com o livro
36
Design Patterns→ Não se refletem em pedaços de códigos ou componentes que são reutilizáveis de forma igual em diversas aplicações
→ Eles são um conhecimento que deve estar na cabeça dos desenvolvedores/arquitetos de software.
→ Avaliar o contexto e o problema que querem resolver→ Utilizar com parcimônia os padrões mais adequados
37
38
“Quanto mais padrões eu utilizar, melhor vai ficar o meu código?”
39
“Quanto mais padrões eu utilizar, melhor vai ficar o meu código?”NÃO
Exercício: Modele e ImplementeA livraria Yoda vende diversos artigos consistindo de Livros, Revistas e Jogos.Há livros e revistas impressos e digitais.A livraria possui Jogos de Tabuleiro e Jogos de Vídeo Game, sendo o último o jogo físico ou digital.
No pagamento a vista, temos a seguinte política de descontos:Livros, Revistas Físicos e Jogos de Tabuleiro: 30% de desconto.Livros e Revistas Digitais: 15% de desconto.Não há desconto para Jogos de Vídeo Game.
40
Referências→ FREEMAN, Eric et al. Head first design patterns. " O'Reilly Media, Inc.", 2004
→ GUERRA, Eduardo. Design Patterns com Java: Projeto orientado a objetos guiado por padrões. Editora Casa do Código, 2014.
→ Apostila de Design Patterns da Caelumhttp://www.caelum.com.br/apostila-java-testes-xml-design-patterns/
41
