Download
1 / 23
E N D
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”).
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)
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
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
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”)
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)
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
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
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
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)
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)
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)
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)
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
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
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
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
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”
MVC um exemplo: • diagrama
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”
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”.
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”.
