2 - Padrões de Interface

Prévia do material em texto

15/03/2010
1
Padrões de Projeto
Carga Horária 67hs
Padrões de Interface
Prof. Giuseppe Anthony N. Lima
giuseppeanl@gmail.com
Instituto Federal de Educação Tecnológica da Paraíba
CST – Sistemas para Internet
Introdução
• Padrões de Interface
– Endereçam contextos nos quais é preciso definir 
ou redefinir o acesso aos métodos de uma classe 
ou de um grupo de classes
• Interface
– Fôrma para serviços (métodos) de classes 
implementadoras
– Determina o uso ou acesso a uma classe qualquer 
a partir dos serviços (métodos) que estão 
disponíveis publicamente.
Introdução
• Uma interface pode ser implementada por 
diferentes classes!
• Uma classe pode implementar diversas 
interfaces!
• Padrões de Projeto e uso de Interfaces
– Uso do polimorfismo como forma de liberar a 
classe de um tipo específico de comportamento
Introdução
• Padrões de Interface
– Adapter
• Adapta a interface de uma classe para corresponder a 
interface esperada pelo cliente
– Façade
• Fornece uma interface simples para um conjunto de classes
– Bridge
• Define uma abstração para que componentes que se 
intercomunicam, que variam de implementação, possam se 
comunicar independentemente disso.
– Composite
• Define uma interface que se aplique a objetos individuais e 
aos grupos de objetos 
• Padrões de Interface
– Abordagem: Como acessar uma classe ou um 
conjunto de classes adequadamente.
Introdução
Essa interface é confusa, 
ainda não entendi como 
utilizar esse componente de 
software!
Adapter
• Converter a interface de uma classe em outra 
interface esperada pelos clientes. Permite a 
comunicação entre classes que não poderiam 
trabalhar juntas devido à incompatibilidade de 
suas interfaces [GoF]
15/03/2010
2
Adapter
• Motivação
– Precisamos implementar uma classe a fim de 
atender a uma demanda de uma outra
– No entanto descobrimos que existe a classe que 
fornece os serviços esperados possui uma 
interface diferente!
Adapter
Adapter
• Representação
Adapter
• Calculadora Simplificada
– Em uma determinada aplicação precisamos de 
uma classe que faça operações aritméticas
– Temos uma API que contém uma classe que faz 
isso!
– Nossa aplicação foi projetada para usar uma certa 
interface e a da API é diferente
– Não podemos mexer no código da API ou da 
aplicação!
Adapter
• Representação 
A classe da API existente possui 
uma interface incompatível com 
a de nosso cliente: veja os 
parâmetros!
Adapter
15/03/2010
3
Adapter Adapter
• O Adapter que vimos até agora é um Object 
Adapter:
– Adaptação é realizada com referência ao objeto a 
ser adaptado na classe adaptadora
– Delega responsabilidade de conversão
• Pequeno bloco de código para delegar ao objeto 
adaptado (cuja interface é incompatível com a do 
cliente)
Adapter
• Object Adapter
– Utiliza composição entre a classe adaptadora e a 
adaptada
Adapter
• Class Adapter
– Utiliza Herança
– O alvo tem que ser a classe utilizada pelo cliente
– A classe Adapter (Adaptador) estende Classe Existente 
(Adaptado) e irá implementar a interface Alvo.
Adapter
• Class Adapter Código
Adapter
• Class Adapter Código
15/03/2010
4
Adapter
• Object Adapter (Conseqüências)
– Permite substituição de comportamentos
– Permite introduzir um ou mais objetos
– Permite usar a hierarquia do objeto incompatível
• Se a classe existente possuir subclasses a adaptação 
funcionará do mesmo jeito
• A referência através de composição no Adaptador, para 
o Adaptado com subclasses garante o funcionamento 
de suas especializações.
Adapter
• Class Adapter (Conseqüências)
– Permite a substituição de comportamentos
• Através de sobrescrita de métodos possível na herança 
com o adaptado
– Adapta somente um objeto existente
• Devido a herança com o adaptado
– Economia de código
• Código do adaptado pode ser herdado ou estendido ( 
sobrescrito)
Adapter Façade
• “Fornecer uma interface unificada para um 
conjunto de classes em um subsistema [GoF]
• Define uma interface de nível mais alto que 
torna o subsistema mais fácil de ser usado 
[GoF]
Façade
• Quanto mais um sistema que é composto por 
diversos outros módulos ou subsistemas, o 
mesmo, se torna difícil de ser utilizado.
Façade
• Como definir uma interface de acesso que 
oculte a relação entre esses subsistemas?
15/03/2010
5
Façade
• Aplicabilidade
– Desejar oferecer uma interface simples para um 
sistema complexo
– Existirem muitas dependências entre os clientes e 
as classes de implementação de uma abstração 
– Desejar estruturar subsistemas em camadas
Façade
• Estrutura
Façade
• Exemplo
– Home-theater
• Dvd player
• Amplificador
• Projetor
• Tela
• Turner
• Etc.
Façade
• Como faríamos para montar o nosso Sistema 
de Home Theater?
– Selecionar os equipamentos necessários
– Dispor os equipamentos selecionados em seus 
lugares pelo ambiente
– Ligar os fios entre os equipamentos quando 
necessário
Façade Façade
15/03/2010
6
Façade
• Utilizando a biblioteca home-theater
Façade
public class Cliente{
...
pipoqueira.ligar();
pipoqueira.fazerPipoca();
tela.baixar();
projetor.ligar();
projetor.setInput(dvd);
projetor.widescreenMode();
amp.ligar();
amp.setDvd(dvd);
amp.setSorroundSound();
amp.setVolume(5);
dvd.ligar();
dvd.play(filme);
...
}
Façade
• Problemas
– O cliente tem que lidar com muitas classes
• Muitas associações
– O cliente tem que conhecer a interface de cada 
uma das classes
• Acoplamento está alto
– Manutenção está prejudicada
Façade
• Solução
Façade Façade
15/03/2010
7
Façade Façade
Façade Façade
• Não encapsula as classes do subsistema.
– Apenas fornece uma interface simplificada à sua 
funcionalidade
– Se alguma classe precisar acessar diretamente a 
funcionalidade, isso ainda poderá ser feito
• Isola os clientes dos subsistemas
– Reduz o número de objetos que os clientes têm de 
lidar 
– Torna o subsistema mais fácil de usar
Façade
• Mais de uma Façade para um mesmo 
subsistema
Façade
• Façade para uma única classe
15/03/2010
8
Façade
• O Padrão Façade encapsula as classes do 
subsistema?
• A Façade pode ser inteligente no sentido de 
que pode adicionar novas funcionalidades ao 
sistema?
Composite
• “Compor objetos em estruturas de árvore 
para compor hierarquias parte-todo”
• “Atribuir um comportamento uniforme a 
objetos primitivos ou compostos”
Composite
• Exemplos de Composições 
– Menus e Submenus são compostos por MenuItem
– Uma peça pode ser composta por outras peças 
mais básicas
– Em um editor de desenho uma figura pode ser 
composta por outras figuras elementares
• Exemplos de Composições 
Composite
• Exemplos de Composições 
Composite
getName();
getDescription();
getAction();
resize();
move();
bringToFront();
sendToBack();
girar();
parar();
Composite
• Composições
– Estrutura hierárquica 
• acesso parte-todo
– Comportamento uniforme
• Os objetos compostos e seus componentes 
“compartilham” comportamentos
15/03/2010
9
Composite
• Um composite representa um grupo de objetos no qual 
alguns deles podem conter outros objetos
– Se pode conter (composite, nó pai)
– Se não pode conter (component, nó ou folha)
Menu
Item de 
menu
Item de 
Menu
FiguraComposta
Círculo Triângulo
Figura 
Composta
Quadrado Losango
Composite
• Modelagem
– Projetar estruturas que possam conter itens 
individuais
– Definir comportamentos comuns para objetos 
componentes e compostos
Composite
• Exemplo
– Uma pequena fábrica que está começando a 
operar contémapenas uma máquina
Composite
Composite
• A fábrica cresceu e novas máquinas foram 
adquiridas...
• Novo cenário
– Máquinas devem ser organizadas em baias
– Cada máquina tem seu responsável
– Cada baia tem seu responsável
– Queremos operar e monitorar as baias e suas 
máquinas remotamente
– Quando a máquina não tiver responsável o 
encarregado da baia assume
Composite
• Fábrica
15/03/2010
10
Composite
• Implementação
– Operações se aplicam tanto as baias quanto as 
máquinas
• ligar(), verEstado(), getResponsavel()
– Lidamos com máquinas e baias em momentos 
diferentes (também!)
– A linha de produção será dotada de uma baia que 
pode conter outras máquinas.
Composite
• Solução
Composite
• A fábrica com Composite
Composite
• Código da Solução
Composite
• Código da Solução
Composite
• Código da Solução
15/03/2010
11
Composite
• Código da Solução
Composite
• Código da Solução
Composite
• Código da Solução (Cliente)
Composite
• Código da Solução (Cliente)
Composite
• Problema...
– O que fazer com os métodos específicos da classe 
composta baia
• Métodos não suportados por componente máquina ou 
exclusivos de baia
– getMaquina(), addMaquina(); removeItem(); procuraItem()
– Alguns comportamentos são similares
• Como prover uma implementação genérica para 
comportamentos comuns do composto e seus 
componentes
– getResp(); setResp();getID(); setID(); setEstado(), getEstado()
Composite
• Solução
– A interface componente passará a ser uma classe 
abstrata
• Métodos não suportados 
– Passam a ter uma implementação genérica na classe abstrata
– Devem conter a especificação de que podem não ser 
suportados: NotSupportedException, ou retornar nulo, etc.
• Métodos comuns
– Possuirão uma implementação genérica na classe abstrata
– Código da classe abstrata é reaproveitado nas subclasses ou 
pode ser adaptado. 
15/03/2010
12
Composite
• Solução
Classe abstrata Métodos não suportados
Composite
• Solução (Componente e Composto)
Composite
• Conseqüências
– Positivas
• Objetos complexos podem ser compostos de objetos 
mais simples recursivamente
– O cliente pode tratar objetos simples ou compostos da mesma 
forma: simplifica o cliente
• Facilita a adição de novos componentes
– O cliente não tem que mudar com a adição de novos objetos 
(simples ou compostos)
– Exemplo: novos componentes poderiam ser adicionados a 
fábrica, como esteiras, empacotadoras, etc. 
Composite
• Conseqüências (Cont.)
– Negativas: o projeto fica geral demais
• É mais difícil restringir os componentes de um objeto 
composto
• Por exemplo, podemos compor esteiras (objeto 
composto de produtos) com baias , o que não faz 
sentido, exceto o contrário
• O sistema de tipagem da linguagem não ajuda a 
detectar composições erradas
– A solução é verificar em tempo de execução
Composite
• Considerações
– Referencias aos filhos e métodos de gerência dos 
filhos
• Em Composite (Compositora)
– Uso seguro pelo cliente
– Adicionar um filho a uma folha não é permitido!
– Cliente deverá utilizar instanceof para acessar métodos de 
gerência (add(), remove(), etc.)
• Em Component (Componente)
– Uso transparente pelo cliente
– Todas as classes folha herdarão o código de gerência e a 
referência aos filhos: adicionar um filho a uma folha possível!
– Referência aos filhos pode ser inutilizada (desperdício de 
espaço em caso de ser um componente folha básico.
Composite
• Considerações (Cont.)
– Referências explicita ao pai
• Facilita o caminho sobre a estrutura (volta)
• Geralmente é colocada na classe Component
– Ordenação de Filhos é possível
• Iterator
– Qual a melhor estrutura de dados
• Qualquer coleção! (List, HashMap)
15/03/2010
13
Bridge
• Intenção
– “Desacoplar uma abstração de sua 
implementação de modo que as duas possam 
variar independentemente.”
• Motivação
– A herança liga uma implementação à abstração 
permanentemente, o que torna difícil modificar, 
aumentar e reutilizar abstrações e 
implementações independentemente.
Bridge
• Solução
– Separar as duas partes através de uma classe que 
intermedia a troca de mensagens
• Classe utiliza métodos cuja finalidade está implícita nos 
seus nomes, mas cuja implementação pode variar e 
cabe às classes concretas
– Podemos mudar a implementação sem afetar a 
abstração e vice-versa.
Bridge
• Solução
Bridge
• Abstração?
– Classe que depende de um conjunto de operações 
abstratas, onde diversas implementações desse 
conjunto são possíveis
• Implementação?
– Classe que implementa de forma específica uma 
interface esperada pela Abstração
Bridge
• Abstração X Implementação
– Uma pessoa X Homem, Mulher, etc.
– Uma figura X Quadrado, Triângulo, Círculo
– Uma máquina X Empacotadora, Engarrafadora
Bridge
• Temos uma aplicação que em princípio se 
utiliza de máquinas para funcionar:
– Máquina engarrafadora
– Máquina rotuladora
15/03/2010
14
Bridge
• Agora nosso projeto mudou...
– Existe um novo tipo de máquina: de teste
– Desejo que as outras máquina possuam uma 
versão de teste!
Bridge
• Nosso projeto mudou 
novamente...
– Agora tenho novos dois 
tipos de máquina: as 
máquinas grandes e as 
pequenas
– As máquinas existentes 
devem possuir ambas 
as características: 
grande ou pequena
Bridge
• Muita Herança?
– A abstração não está separada da implementação
– Ao utilizar um novo tipo o cliente deverá estar 
ciente disso (projeto inflexível)
• Ainda...
– A implementação deve variar em tempo de 
execução
Bridge
• Solução
Bridge
• Solução para a nossa aplicação...
Bridge
15/03/2010
15
Bridge
• Drivers
Bridge
• JDBC
Bridge
• Considerações
– Evitar ligação permanente entre uma abstração e sua 
implementação. Pode ser, por exemplo, quando se 
deseja variar a implementação em run-time
– Tanto a abstração quanto a implementação devem ser 
extensíveis através de herança
– Mudanças na implementação de uma abstração não 
devem ter impacto sobre o cliente
– A proliferação de classes dividindo o objeto em duas 
partes é evitada
– Você que compartilhar uma implementação entre 
múltiplos objetos e este fato deve ser escondido do 
cliente.