1 padrões - introdução o que é um padrão? each pattern describing a problem which occurs over...
TRANSCRIPT
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?
6Desenho 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”)
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 sub-classeamento (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”.