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

1

Padrão - 4 elementos essenciais

2 • 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 3

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 4

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?

5

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

Desenho OO - especificação de interfaces

7 • 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 8

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 9

Desenho OO - reutilização - tipos

10

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) 11

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) 12

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) 13

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) 14

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 15

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 16

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 17

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 18

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

MVC um exemplo:

• diagrama 20

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

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

22

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