Argo Navis J930 - Padres de Design

1 - Introduo

J930

Padres de

Projeto
Introduo
argonavis.com.br

Helder da Rocha (helder@acm.org)

O que um padro?
Maneira testada ou documentada de alcanar um objetivo qualquer
Padres so comuns em vrias reas da engenharia

Design Patterns, ou Padres de Projeto

Padres para alcanar objetivos na engenharia de software usando classes e mtodos em linguagens orientadas a objeto Inspirado em "A Pattern Language" de Christopher Alexander, sobre padres de arquitetura de cidades, casas e prdios "Design Patterns" de Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm, conhecidos como "The Gang of Four", ou GoF, descreve 23 padres de projeto teis.
2

2003, Helder L. S da Rocha

1-1

Argo Navis J930 - Padres de Design

1 - Introduo

O que um padro?
"Cada padro descreve um problema que ocorre repetidas vezes em nosso ambiente, e ento descreve o ncleo da soluo para aquele problema, de tal maneira que pode-se usar essa soluo milhes de vezes sem nunca faz-la da mesma forma duas vezes"
Christopher Alexander, sobre padres em Arquitetura

"Os padres de projeto so descries de objetos que se comunicam e classes que so customizadas para resolver um problema genrico de design em um contexto especfico"
Gamma, Helm, Vlissides & Johnson, sobre padres em software
3

Por que aprender padres?

Aprender com a experincia dos outros
Identificar problemas comuns em engenharia de software e utilizar solues testadas e bem documentadas Utilizar solues que tm um nome: facilita a comunicao, compreenso e documentao

Aprender a programar bem com orientao a objetos

Os 23 padres de projeto "clssicos" utilizam as melhores prticas em OO para atingir os resultados desejados

Desenvolver software de melhor qualidade

Os padres utilizam eficientemente polimorfismo, herana, modularidade, composio, abstrao para construir cdigo reutilizvel, eficiente, de alta coeso e baixo acoplamento
4

2003, Helder L. S da Rocha

1-2

Argo Navis J930 - Padres de Design

1 - Introduo

Por que aprender padres?

Vocabulrio comum
Faz o sistema ficar menos complexo ao permitir que se fale em um nvel mais alto de abstrao

Ajuda na documentao e na aprendizagem

Conhecendo os padres de projeto torna mais fcil a compreenso de sistemas existentes "As pessoas que esto aprendendo POO freqentemente reclamam que os sistemas com os quais trabalham usam herana de forma convoluida e que difcil de seguir o fluxo de controle. Geralmente a causa disto que eles no entendem os padres do sistema" [GoF] Aprender os padres ajudam um novato a agir mais como um especialista
5

Por que aprender padres?

Uma prtica adjunta aos mtodos existentes
Mostram como usar prticas primitivas Descrevem mais o porqu do design Ajudam a converter um modelo de anlise em um modelo de implementao

Um alvo para refatoramento

Captura as principais estruturas que resultam do refatoramento Uso de patterns desde o incio pode diminuir a necessidade de refatoramento
6

2003, Helder L. S da Rocha

1-3

Argo Navis J930 - Padres de Design

1 - Introduo

Elementos de um padro
Nome Problema
Quando aplicar o padro, em que condies?

Soluo
Descrio abstrata de um problema e como usar os elementos disponveis (classes e objetos) para solucion-lo

Conseqncias
Custos e benefcios de se aplicar o padro Impacto na flexibilidade, extensibilidade, portabilidade e eficincia do sistema
7

Formas de classificao
H vrias formas de classificar os padres. Gamma et al [1] os classifica de duas formas
Por propsito: (1) criao de classes e objetos, (2) alterao da estrutura de um programa, (3) controle do seu comportamento Por escopo: classe ou objeto

Metsker [2] os classifica em 5 grupos, por inteno (problema a ser solucionado):

(1) oferecer uma interface, (2) atribuir uma responsabilidade, (3) realizar a construo de classes ou objetos (4) controlar formas de operao (5) implementar uma extenso para a aplicao
8

2003, Helder L. S da Rocha

1-4

Argo Navis J930 - Padres de Design

1 - Introduo

Classificao dos 23 padres segundo GoF*

Propsito 1. Criao Escopo Classe Objeto
Factory Method Abstract Factory Builder Prototype Singleton

2. Estrutura
Class Adapter Object Adapter Bridge Composite Decorator Facade Flyweight Proxy

3. Comportamento
Interpreter Template Method Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

* Padres "clssicos" selecionados e organizados por Gamma et al. "Design Patterns" [1]

Classificao dos padres GoF segundo Metsker [2]

Inteno 1. Interfaces 2. Responsabilidade 3. Construo 4. Operaes 5. Extenses Padres Adapter, Facade, Composite, Bridge Singleton, Observer, Mediator, Proxy, Chain of Responsibility, Flyweight Builder, Factory Method, Abstract Factory, Prototype, Memento Template Method, State, Strategy, Command, Interpreter Decorator, Iterator, Visitor

Neste curso usaremos esta classificao

10

2003, Helder L. S da Rocha

1-5

Argo Navis J930 - Padres de Design

1 - Introduo

Relacionamentos entre os 23 padres "clssicos"

Fonte: [1]

11

Finalidade dos 23 padres: Interface

1. Adapter
Converter a interface de uma classe em outra interface esperada pelos clientes.

2. Faade
Oferecer uma interface nica de nvel mais elevado para um conjunto de interfaces de um subsistema

3. Composite
Permitir o tratamento de objetos individuais e composies desses objetos de maneira uniforme

4. Bridge
Desacoplar uma abstrao de sua implementao para que os dois possam variar independentemente
12

2003, Helder L. S da Rocha

1-6

Argo Navis J930 - Padres de Design

1 - Introduo

Finalidade dos padres: Responsabilidades

5. Singleton
Garantir que uma classe s tenha uma nica instncia, e prover um ponto de acesso global a ela

6. Observer
Definir uma dependncia um-para-muitos entre objetos para que quando um objeto mudar de estado, os seus dependentes sejam notificados e atualizados automaticamente

7. Mediator
Definir um objeto que encapsula a forma como um conjunto de objetos interagem
13

Finalidade dos padres: Responsabilidades

8. Proxy
Prover um substituto ou ponto atravs do qual um objeto possa controlar o acesso a outro

9. Chain of Responsibility
Compor objetos em cascata para, atravs dela, delegar uma requisio at que um objeto a sirva

10. Flyweight
Usar compartilhamento para suportar eficientemente grandes quantidades de objetos complexos

14

2003, Helder L. S da Rocha

1-7

Argo Navis J930 - Padres de Design

1 - Introduo

Finalidade dos 23 padres: Construo

11. Builder
Separar a construo de objeto complexo da representao para criar representaes diferentes com mesmo processo

12. Factory Method

Definir uma interface para criar um objeto mas deixar que subclasses decidam que classe instanciar

13. Abstract Factory

Prover interface para criar famlias de objetos relacionados ou dependentes sem especificar suas classes concretas

14. Prototype
Especificar tipos a criar usando uma instncia como prottipo e criar novos objetos ao copiar este prottipo

15. Memento

Externalizar o estado interno de um objeto para que o objeto possa ter esse estado restaurado posteriormente
15

Finalidade dos 23 padres: Operaes

16. Template Method
Definir o esqueleto de um algoritmo dentro de uma operao, deixando alguns passos a serem preenchidos pelas subclasses

17. State
Permitir a um objeto alterar o seu comportamento quanto o seu estado interno mudar

18. Strategy
Definir uma famlia de algoritmos, encapsular cada um, e faz-los intercambiveis

19. Command
Encapsular requisio como objeto, para clientes parametrizarem diferentes requisies, filas, e suportar operaes reversveis

20. Interpreter
Dada uma linguagem, definir uma representao para sua gramtica junto com um interpretador
16

2003, Helder L. S da Rocha

1-8

Argo Navis J930 - Padres de Design

1 - Introduo

Finalidade dos 23 padres: Extenso

21. Decorator
Anexar responsabilidades adicionais a um objeto dinamicamente

22. Iterator
Prover uma maneira de acessar elementos de um objeto agregado seqencialmente sem expor sua representao interna

23. Visitor
Representar uma operao a ser realizada sobre os elementos de uma estrutura de objetos
17

Como os padres solucionam problemas

Problema 1: quais os objetos mais apropriados?
A tarefa de decompor um sistema em objetos no trivial preciso levar em conta fatores como encapsulamento, granularidade, dependncia, flexibilidade, performance, reuso, etc. Muitos objetos so descobertos na fase de anlise, mas muitos no tm paralelo no mundo real

Design patterns ajudam a identificar as abstraes menos bvias e objetos que podem represent-las
Exemplo: objetos que representam um algoritmo ou um estado (raramente aparecem na fase de anlise)
18

2003, Helder L. S da Rocha

1-9

Argo Navis J930 - Padres de Design

1 - Introduo

Como os padres solucionam problemas

Problema 2: qual a granularidade ideal?
Objetos podem representar qualquer coisa Um objeto pode representar todos os detalhes at o hardware ou ser a aplicao inteira

Design patterns oferecem vrias solues

Faade descreve como representar subsistemas inteiros como um nico objeto Flyweight descreve como suportar grandes quantidades de objetos nas menores granularidades Abstract Factory, Builder, Visitor e Command limitam a responsabilidade de objetos
19

Como os padres solucionam problemas

Problema 3: como especificar interfaces?
Uma interface o conjunto de todas as assinaturas* definidas pelas operaes de um objeto Objetos so conhecidos apenas atravs de suas interfaces em sistemas orientados a objetos A interface de um objeto nada diz sobre sua implementao, que pode ser determinada em tempo de execuo

Design patterns ajudam a definir interfaces ao identificar seus elementos-chave e tipos de dados que so passados
Podem restringir o que se pode colocar em uma interface Podem especificar relacionamentos entre interfaces Podem estabelecer regras para criao de interfaces
* Nome da operao, objetos que recebe como parmetros e valor de retorno
20

2003, Helder L. S da Rocha

1 - 10

Argo Navis J930 - Padres de Design

1 - Introduo

Como os padres solucionam problemas

Problema 4: como especificar implementaes
Objetos s devem ser manipulados em termos de uma interface definida por classes abstratas (ou interfaces Java) Clientes no devem conhecer os tipos concretos dos objetos, nem das classes que implementam esses objetos. S devem conhecer as classes abstratas que definem a interface Princpio de design reutilizvel: programe para uma interface, nunca para uma implementao

Design patterns oferecem formas de instanciar classes concretas em outras partes do sistema
Padres de construo abstraem o processo de criao de objetos oferecendo um meio transparente para associar uma interface com uma implementao.
21

Como os padres solucionam problemas

Problema 5: Como fazer o reuso funcionar
Deve-se usar herana de classes com cautela. H quebra de encapsulamento na herana porque ela expe a subclasse a detalhes da implementao da superclasse Dando preferncia composio de objetos sobre herana de classes ajuda a manter o encapsulamento e o foco de cada classe em uma nica tarefa Princpio de design reutilizvel: d preferncia composio de objetos sobre herana de classe

Design patterns usam delegao para tornar a composio to poderosa para reuso quando a herana
Dois objetos esto envolvidos para tratar uma requisio: o objeto que recebe a requisio passa uma referncia de si mesmo para o objeto delegado

22

2003, Helder L. S da Rocha

1 - 11

Argo Navis J930 - Padres de Design

1 - Introduo

Delegao
Exemplo: Janela tem um retngulo (em vez de ser um)
Janela area() Retngulo altura largura area()
return retangulo.area() return largura * altura

Vantagem: facilita a composio de comportamentos em tempo de execuo Desvantagem: possvel performance menor; cdigo mais difcil de acompanhar.
Delegao uma boa escolha de design somente quando ela simplifica mais que complica! Funciona melhor quando usada de forma padro: Patterns!

23

Como os padres solucionam problemas

Problema 6: como distinguir estruturas estticas (compile-time) e dinmicas (run-time)
A estrutura em tempo de execuo de um programa orientado a objetos mantm pouca semelhana com sua estrutura de cdigo: cdigo no revela como sistema funciona! Estrutura esttica: hierarquias fixas e imutveis Estrutura dinmica: redes mutveis de objetos interagindo Exemplo: agregao e associao so implementadas da mesma forma (em cdigo) mas se mostram muito diferentes em tempo de execuo

Vrios design patterns capturam a distino entre estruturas run-time e compile-time

As estruturas no so bvias pelo cdigo. preciso entender os padres!
24

2003, Helder L. S da Rocha

1 - 12

Argo Navis J930 - Padres de Design

1 - Introduo

Problema 7: como antecipar mudanas?

Os padres viabilizam o desenvolvimento de cdigo mais robusto diante de possveis mudanas e refatoramento do cdigo Padres promovem desacoplamento e permitem que algum aspecto da estrutura do sistema varie independentemente de outros aspectos
Evita redesign e readaptao de cdigo nas situaes previstas pelo padro aplicado Reduz risco e possveis custos futuros Na maior parte dos casos, o investimento no implica em altos custos (risco) no presente, j que contribuem para a legibilidade e qualidade do cdigo.
25

Oito causas comuns de redesign e padres que os evitam [1]

1. Criao de objeto especifica classe explicitamente
O sistema est preso a uma implementao especfica Soluo: criar objetos indiretamente com Abstract Factory, Factory Method ou Prototype

2. Dependncia em operaes especficas

O sistema s tem uma forma de satisfazer uma requisio Soluo: evitar aes "hard-coded" com Chain of Responsibility ou Command

3. Dependncia em plataforma de H/W ou S/W

O software precisa ser portado a outras plataformas Soluo: limitar dependncias com Abstract Factory ou Bridge

4. Dependncia em representaes ou implementaes de objetos

Clientes que sabem como um objeto implementado, representado ou armazenado podem ter que ser alterados se o objeto mudar Soluo: isolar cliente com Abstract Factory, Bridge, Memento ou Proxy
[1] Pags. 24 e 25
26

2003, Helder L. S da Rocha

1 - 13

Argo Navis J930 - Padres de Design

1 - Introduo

Oito causas comuns de redesign e padres que os evitam [1]

5. Dependncias de algoritmo
Mudanas de algoritmo so freqentes. Objetos que dependem de um algoritmo precisam mudar quando o algoritmo mudar. Soluo: isol-los com Builder, Iterator, Strategy, Template Method ou Visitor

6. Forte acoplamento
Classes fortemente acopladas so difceis de reusar, testar, manter, etc. Soluo: enfraquecer o acoplamento com Abstract Factory, Bridge, Chain of Responsibility, Command, Faade, Mediator ou Observer

7. Extenso de funcionalidade atravs de subclasses

Herana difcil de usar; composio dificulta compreenso. Soluo: usar padres que implementam bem herana e composio como Bridge, Chain of Responsibility, Composite, Decorator, Observer ou Strategy

8. Incapacidade de alterar classes convenientemente

Classes inaccessveis, incompreensveis ou difceis de alterar Soluo: usar Adapter, Decorator ou Visitor
27

Tipos de software
Aplicaes
Prioridades: reuso interno, manuteno, extenso

Toolkits, APIs, bibliotecas

Conjunto de classes reutilizveis de propsito geral. No impem design Prioridade: amplo reuso de cdigo

Frameworks
Dita a arquitetura da aplicao. Requer que usurio aprenda o framework e inclua cdigo e configurao. Prioridade: amplo reuso de design Geralmente so fortemente baseados em padres. Quem conhee os padres entende o framework mais facilmente.
28

2003, Helder L. S da Rocha

1 - 14

Argo Navis J930 - Padres de Design

1 - Introduo

Aspectos de design que padres permitem variar

Design Pattern Abstract Factory Builder Factory Method Prototype Singleton Adapter Bridge Composite Decorator Faade Flyweight Proxy Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor Fonte: [1] Pag. 30 Aspecto(s) que pode(m) variar famlias de objetos de produtos como um objeto composto criado subclasse de objeto que instanciado classe de objeto que instanciado a nica instncia da classe interface para um objeto implementao de um objeto estrutura e composio de um objeto responsabilidades de um objeto sem recorrer a subclasses interface para um subsistema custos de armazenamento de objetos como um objeto acessado; sua localizao objeto que pode satisfazer uma requisio quando e como uma requisio satisfeita gramtica e interpretao de uma linguagem como os elementos de um agregado so acessados como e quais objetos interagem uns com os outros que informao privativa armazenada fora de um objeto, e quando nmero de objetos que dependem de outro objeto e como eles se mantm em dia estados de um objeto um algoritmo passos de um algoritmo operaes que podem ser aplicadas a objetos sem mudar suas classes 29

Como selecionar um padro?

1. 2. 3. 4. 5. 6. Considere como os padres solucionam os problemas de projeto Analise seu problema e compare com o objetivo de cada padro Veja como os padres envolvidos se relacionam entre si Estude padres de propsito ou inteno similar (veja formas de classificao) Examine causas comuns que podem forar o redesign do seu sistema Considere o que deve variar no seu design
30

2003, Helder L. S da Rocha

1 - 15

Argo Navis J930 - Padres de Design

1 - Introduo

Fontes
[1]

Steven John Metsker, Design Patterns Java Workbook. Addison-Wesley, 2002 [2] Erich Gamma et al. Design Patterns: Elements of Reusable Object-oriented Software. Addison-Wesley, 1995. Parte I foi principal referncia para este captulo.

31

Curso J930: Design Patterns

Verso 1.1

www.argonavis.com.br
2003, Helder da Rocha (helder@acm.org)

2003, Helder L. S da Rocha

1 - 16