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”.