1
Padrões - introdução
O que é um padrão?
“Each pattern describing a problem which occurs over
and over again in our environment, and then
describes the core of the solution to that problem, in
such a way that you can use this solution a million
times over, withough ever doing the same way twice”
(Christopher Alexander- “A pattern language”).
2
Padrão - 4 elementos essenciais
• Nome
• Problema (descrição)
• Solução (Descrição abstrata)
–
–
–
–
elementos
relações
colaborações
responsabilidades
• Conseqüências
– resultados, vantagens, desvantagens (questões de linguagem,
tempo, impacto na flexibilidade, extensibilidade, portabilidade)
3
Descrevendo um padrão- 1
• Nome e classificação
– bom nome é essencial
– "criacional", estrutural (composição de objetos),
comportamental (responsabilidades, interação)
• Propósito
– o que faz? qual o propósito? qual o problema que é
resolvido?
• Outros Nomes
• Motivação
– um exemplo que ilustra o problema e como ele é
resolvido pelo padrão
4
Descrevendo um padrão - 2
• Aplicabilidade
– quando podemos aplicar? que exemplos de má
arquitetura ele resolve?
• Estrutura
– representação gráfica das classes envolvidas
• Participantes
– classes e objetos envolvidos e suas responsabilidades
• Colaborações
5
Descrevendo um padrão - 3
• Conseqüências
– como o padrão resolve o problema? quais são as vantagens e
desvantagens?
• Implementação
– quais os cuidados? dicas? existem questões específicas para
algumas linguagens?
• Exemplo de código
• Usos conhecidos
• Padrões relacionados
– quais padrões são semelhantes? quais as diferenças importantes?
quais outros padrões devem ser utilizados conjuntamente?
Desenho de Aplicações
Orientadas a Objeto (como
padrões podem ajudar?)
• Encontrar os objetos apropriados
–
–
–
–
Objeto: dados + operações
nomes + verbos
colaborações e responsabilidades
modelar mundo real (Ruim - nem todos os objetos tem
similar)
– Padrões ajudam a encontrar abstrações não triviais
• Determinar granularidade (como decidir?) (e.g..
“Factory”)
6
7
Desenho OO - especificação de
interfaces
•
•
•
•
Interface: conjunto de assinaturas
Tipo ~ Interface (supertipo, subtipo)
Interface != Implementação
Padrões
– identificam elementos chaves das interfaces
– tipos de dados enviados pelas interfaces
– o que não colocar em uma interface (e.g. 2 interfaces,
cópia e guardar estado)
– restrições a interfaces (classes que devem ter interfaces
semelhantes)
8
Desenho OO - reutilização herança vs. composição
• caixa branca vs. caixa preta
• mais funcionalidade por código vs. por
composição
• estático vs. dinâmico
• facilidade de modificação vs. modularidade
e encapsulamento
• menos objetos vs. menos classes
• Favorecemos Composição
9
Desenho OO -reutilização delegação
• composição tão poderosa como herança
• análogo a subclasse deixar requisição para ser
tratada por superclasse
– ex. janela delega cálculo de área para retângulo
• Cuidados
–
–
–
–
necessário passar objeto original como parâmetro
"software" altamente parametrizado difícil de escrever
utilizar apenas quando simplifica desenho
deve fazer parte de desenho altamente abstrato
10
Desenho OO - reutilização - tipos
parametrizados
• templates (C++), generics (Ada, Eiffel)
• define tipo sem especificar todos os tipos
que ele utiliza
• versões específicas são criadas para cada
parâmetro
11
Desenho OO - reutilização exemplo
• Algoritmo de ordenação, comparação
– implementada por subclasses (herança)
– responsabilidade do objeto a ser ordenado
(delegação)
– argumento de uma “template” (parametrização)
12
Desenho OO - reutilização diferenças
• Composição de Objetos menos eficiente,
mais dinâmico
• Herança e Parametrização mais eficientes,
estáticas
• Parametrização inexiste em linguagens sem
tipos estáticos (não é necessária)
13
Desenho OO - prevendo
mudanças
• Padrões podem ajudar a desenvolver sistemas mais
tolerantes a mudanças eles podem ajudar de varias
maneiras
• Padrões para criação indireta de objetos, impedem
associação a uma classe específica (Abstract Factory,
Factory Method, Prototype)
• Evitar associar satisfação de tarefa a implementação
específica (Chain of Responsability, Command)
• Evitar dependências com plataformas (Abstract Factory,
Bridge)
14
Desenho OO - prevendo
mudanças - 2
• Evitar dependências com implementações ou representações
específicas de objetos (Abstract Factory, Bridge, Memento, Proxy)
– Evitar dependências em relação a algoritmos específicos (Builder, Iterator,
Strategy, Template Method, Visitor)
• Evitar “tight-coupling” (classes com interdependência forte, onde uma
não pode ser entendida sem saber o funcionamento da outra) (Abstract
Factory, Bridge, Chain of Responsability, Command, Façade,
Mediator, Observer)
• Extensão de funcionalidade por composição e não por subclasseamento (Bridge, Chain of Responsibility, Composite, Decorator,
Observer, Strategy)
• Moficar classes “difíceis” (e.g. não temos o código fonte) (Adapter,
Decorator, Visitor)
15
Padrões não são caixas de
ferramentas (toolkits)
• caixas de ferramentas são bibliotecas de
aplicativos que podem ser utilizados dentro
de uma aplicação
• caixas de ferramentas são conjuntos de
aplicativos com função genérica
• generalidade como em padrões, mas
implementação específica e maior escopo
16
Padrões não são “frameworks”
• função inversa a das caixas de ferramentas:
conjunto de classes cooperantes para o qual
o usuário escreve os aplicativos auxiliares
• todas as aplicações geradas têm a mesma
estrutura, como em padrões
• diferentemente de padrões
– especificação de padrões é mais abstrata
– padrões são unidades menores
– padrões são menos especializados
17
Selecionando um padrão
• importante conhecer conjunto de padrões e
sua inter-relação
• isolar variabilidade no problema tratado
• selecionar padrões com a motivação correta
(intent)
• entender padrões com função semelhante
• tentar evitar causas de reengenharia
utilizando padrões que as combatem
18
Utilizando um padrão
• estudar padrão em detalhe para compreender
responsabilidades e colaborações
• escolher nomes adequados para os participantes
que reflitam sua utilização no domínio escolhido
(nomes ruins indicam classes mal definidas)
• definir as classes
• definir nomes para operações que sejam
adequados ao domínio do problema
• implementar as operações
19
Exemplo de aplicabilidade Model View Controller
• Em Smalltalk aplicações que utilizam interfaces visuais
utilizam o modelo MVC
– Modelo representa os dados
– View representa a(s) aparência(s) visual(is)
– Controler represnta como o aplicativo reage a ações do usuário
• MVS separa estes elementos para criar um modelo padrão
de interface e para possibilitar uma maior modularidade
nos projetos de interface
• Models e Views podem ser independentes porque se
comunicam por uma interface padrão de “notificação” e
“assinatura”
20
MVC um exemplo:
• diagrama
21
MVC e padrões
• apesar de MVC se destinar especificamente à
criaçao de interfaces, este desenho que separa o
modelo de sua representação externa reflete um
princípio mais geral onde a modificação de um
objeto (modelo) pode refletir em vários outros (as
representações). Este princípio é descrito pelo
padrão “Observer”
22
MVC e padrões - 2
• em MVC as representações (“View”) podem ser
encaixadas. Por exemplo um painel de controle
pode ser visto como uma representação composta
de sub-representações (botões, graficos). Este tipo
de desenho é descrito pelo padrão “Composite”.
23
MVC e padrões - 3
• finalmente, em MVC podemos mudar a maneira
pela qual um aplicativo responte à entrada do
usuário mantendo seu modelo e sua represntação
mas mudando o componente controlador. Este tipo
de relação é descrita pelo padrão “Strategy”.