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