Padrões de Desenho (Design Patterns)

Padrões de Desenho (Design Patterns) O que são padrões de desenho Porque são úteis Conhecer alguns padrões 1 Padrões (Patterns) Design Patterns Explained: A New Perspective on Object-Oriented Design, Alan Shalloway e James R. Trott, Addison Wesley, 2ª Ed., 2005: http://www.netobjectives.com/dpexplained/ Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, e John Vlissides, Addison-Wesley Professional, 1ª Ed., 1995 Applying UML and Patterns: An Introduction to Object- Oriented Analysis and Design and the Unified Process, Craig Larman, Prentice Hall PTR; 2ª Ed., 2001 Patterns and Software: Essential Concepts and Terminology, http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html 2 1

Estruturas podem ser diferentes mas resolverem o mesmo problema marcar uma entrada Padrão? Christopher Alexander, planeamento urbanístico e arquitectura Olhando para as estruturas que resolvem problemas semelhantes, Alexander achava que podia encontrar as semelhanças entre desenhos que tinham grande qualidade. A estas semelhanças chamou PADRÕES Padrões são soluções para um problema num contexto Cada padrão descreve um problema que ocorre várias vezes no nosso ambiente e a parte fundamental da solução desse problema, de tal forma que se pode usar a solução milhões de vezes, sem repetir da mesma maneira duas vezes 3 Padrões Segundo Alexander a descrição de um padrão envolve 4 componentes: O nome do padrão O objectivo do padrão, o problema que resolve Como se consegue obter As restrições e forças a considerar para o obter 4 2

De Padrões de Arquitectura para padrões de Desenho de Software Soluções de software descritas em termos de objectos e interfaces em vez de paredes e portas O que é verdadeiro para padrões de arquitectura também é verdadeiro para desenho de software? Há problemas no software que ocorrem várias vezes que poderiam ser resolvidos mais ou menos da mesma maneira? Será possível desenhar software em termos de padrões, criando determinadas soluções baseadas nestes padrões 5 Padrões breve história Christopher Alexander The Timeless Way of Building, 1979 A pattern language: towns, buildings, construction, 1977 1987 Conferência OOPSLA, Ward Cunningham e Kent Beck Jim Coplien, 1991: C++ Idioms GoF = Gang of Four = Erich Gamma, Richard Helm, Ralph Johnson, e John Vlissides, 1995 Design Patterns Aplica a ideia de padrões ao desenho de software chama-lhe padrões de desenho Descreve uma estrutura para catalogar e descrever padrões de desenho Cataloga 23 padrões Postula estratégias e aproximações OO baseadas em padrões de desenho 6 3

Principais características de um padrão Nome: Nome único que identifica o padrão Intenção: O objectivo do padrão; o que faz o padrão? Problema: O problema que o padrão tenta resolver Solução: Como o padrão fornece uma solução para o problema no contexto em que este aparece Participantes e colaboradores: As entidades envolvidas no padrão e como se interligam Consequências: Como é que o padrão suporta os seus objectivos? Quais as consequências da utilização do padrão? Implementação: Como é que o padrão pode ser implementado? Que técnicas se devem usar para implementar o padrão? Há aspectos dependentes de linguagens? Estrutura genérica: Um diagrama standard que mostre a estrutura típica do padrão 7 Porque estudar padrões de desenho? Desenhar software reutilizável Especialistas em desenho software OO não começam sempre do zero a construir um sistema Reutilizam soluções que já provaram funcionar Quando encontram uma boa solução usam-na várias vezes Desenhar com base em experiência anterior 8 4

Porque estudar padrões de desenho? Sensação de já ter resolvido um problema igual, sem saber exactamente onde e como Se lembrasse os detalhes desse problema e como tinha sido resolvido, poder-se-ia reutilizar esse conhecimento, em vez de o redescobrir de novo Normalmente não registamos as experiências para outros usarem Encontrar algo que permita partilhar as experiências 9 Porque estudar padrões de desenho? Reutilizar soluções Definir uma terminologia comum Padrões dão uma perspectiva de mais alto nível do problema, evitando os pormenores numa fase demasiado cedo do desenvolvimento Melhorar a manutenção e modificação do código 10 5

Classificação de padrões segundo GoF Fonte: Gamma et al. 1995 Criação de objectos Composição das classes ou objectos Caracterizam a forma como as classes ou objectos interactuam e distribuem responsabilidades 11 Padrão FACADE (fachada) Intenção: Fornecer uma interface unificada para um conjunto de interfaces num subsistema. Define uma interface de alto nível que torna o subsistema mais fácil de usar (GoF) 12 6

Principais características do Padrão FACADE Intenção: Simplificar o uso de um sistema existente. Precisa de definir a uma interface Problema: Só é preciso usar uma parte do sistema, ou pretende-se interactuar com o sistema de uma dada maneira Solução: Apresenta uma nova interface para o cliente do sistema existente Participantes e colaboradores: Facade e classes do sistema; clientes comunicam com o sistema mandando mensagens ao Facade, que as reenvia para o subsistema apropriado. Os clientes que usam o Facade não precisam de aceder directamente aos objectos do subsistema Consequências: Simplifica o uso do sistema existente; promove um fraco acoplamento entre o subsistema e os seus clientes; contudo como facade não é completo, alguma funcionalidade pode não estar disponível para o cliente Implementação: Definir uma nova classe (ou classes) que tem a interface requerida. Colocar a nova classe a usar o sistema existente. 13 Principais características do Padrão FACADE Estrutura genérica: 14 7

15 Aplicação do padrão Facade Não é preciso usar toda a funcionalidade do sistema complexo, e podese criar uma classe que contenha todas as regras para aceder a esse sistema. Se este é um subconjunto do sistema original, a API (application programming interface) criada é muito mais simples Pretende-se encapsular o sistema original Monitorar utilização do sistema Trocar sistemas Pretende-se usar a funcionalidade do sistema original, mas também adicionar alguma O custo de escrever esta nova classe é menor do que o custo de todos terem que aprender o sistema original, ou menor do que se iria gastar em manutenção no futuro Facade põe uma nova interface (fachada) em frente do sistema original 16 8

Padrão ADAPTER (adaptador) Converte a interface de uma classe numa outra interface que o cliente espera. Permite que as classes trabalhem em conjunto, o que não poderiam fazer por motivos de incompatibilidades de interface (GoF) Usar Polimorfismo 17 Como fazer? Pretende-se agora adicionar uma nova forma Circulo Necessário implementar métodos display, fill e undisplay Melhor: alguém tem uma classe que se pode usar XXCircle +setlocation() +getlocation() +displayit() +fillit() +setitscolor() +undisplayit() 18 9

Padrão Adapter Não se pode usar a classe XXCircle directamente porque: Temos nomes e listas de parâmetros diferentes Não se pode derivar de Shape Podia modificar XXCircle efeitos laterais Em vez de mudar, adaptá-la 19 Implementar o padrão Adapter Circle contém XXCircle Class Circle extends Shape { private XXCircle MyXXCircle; Public Circle () { myxxcircle = new XXCircle(); } Void public display() { myxxcircle.displayit(); } } 20 10

Principais características do Padrão Adapter Intenção: casa o comportamento de um objecto existente fora do nosso controlo, com uma dada interface Problema: Um sistema que tem o comportamento e os dados certos mas uma interface errada; tipicamente usado quando se tem que fazer que algo derive de uma classe abstracta Solução: Fornece um invólucro (empacotador) com a interface desejada Participantes e colaboradores: O Adapter adapta a interface de um Adaptado para casar com a do alvo do Adapter (a classe da qual deriva); isto permite que o Cliente use o Adapatdo como se ele fosse um tipo do alvo Consequências: Permite que objectos preexistentes encaixem em estruturas de novas classes, sem estarem limitados pelas suas interfaces Implementação: Contém a classe existente numa outra classe. Fazer com que a classe que contém case com a interface requerida e chame os métodos da classe contida 21 Principais características do Padrão Adapter Estrutura genérica: Object Adapter um objecto (adaptador) contém outro objecto (adaptado) Class Adapter usando herança múltipla 22 11

Comparar os padrões Facade e Adapter Facade Adapter Há classes preexistentes? Sim Sim Há uma interface que também é preciso desenhar? Há um objecto que deve ter comportamento polimorfo? È necessária uma interface mais simples? Não Não Sim Sim Provavelment e Não Ambos são Wrappers empacotadores Um Facade simplifica uma interface Um Adapter converte uma interface existente numa outra 23 Padrão Strategy (estratégia) Sistema de comércio electrónico Processar encomendas em diferentes países» Preencher a encomenda» Calcular taxas» Processar a encomenda e emitir um recibo Desenhar com mudança na mente não é tentar antecipar a natureza exacta da mudança, mas sim assumir que haverá mudanças, e tentar antecipar onde elas ocorrerão Novos requisitos alterar a forma de cálculo das taxas; calcular taxas para clientes de outros países adicionar novas regras de cálculo Como fazer? 24 12

Copy + paste Switches Herança Segundo GoF Considerar o que deve ser variável no desenho e encapsular o conceito que varia Favorecer agregação-objecto em vez de herança-classe 25 No exemplo regras de cálculo das taxas variam Para encapsular deverá criar-se uma classe abstracta que define conceptualmente como se calcula uma taxa, derivando-se classes concretas para cada variação 26 13

Favorecer agregação em vez de herança 27 Padrão Strategy Definir uma família de algoritmos, encapsular cada um, e torná-los permutáveis; permite que o algoritmo varie independentemente do clientes que o usam (GoF) Baseado nos princípios: Objectos têm responsabilidades Implementações diferentes, específicas destas responsabilidades são manifestadas através do polimorfismo Há a necessidade de gerir diferentes implementações do que é, conceptualmente, o mesmo algoritmo Boa prática de desenho separar os comportamentos do domínio do problema uns dos outros alterar a classe responsável por um comportamento sem alterar outras 28 14

Principais características do Padrão Strategy Intenção: Permite usar diferentes regras de negócio ou algoritmos dependendo do contexto onde ocorrem Problema: A selecção do algoritmo a ser aplicado depende de um pedido do cliente ou dos dados que estão a ser usados. Se apenas houver uma regra, que não muda, então não é necessário o Strategy Solução: Separar a selecção do algoritmo da sua implementação. Permitir que a selecção seja feita com base no contexto Participantes e colaboradores: Strategy especifica como são usados os diferentes algoritmos ConcreteStrategies implementam esses algoritmos Context usa um dado ConcreteStrategy com uma referência do tipo Strategy. Startegy e Context interagem para implementar o algoritmo escolhido. O Context reencaminha o pedido do seu cliente para o Strategy Consequências: Define uma família de algoritmos Permite eliminar switches e/ou condições Todos os algoritmos têm que ter a mesma interface 29 Principais características do Padrão Strategy Implementação: Fazer com que a classe que usa o algoritmo (context) contenha uma classe abstracta (Strategy) que tem um método abstracto que especifica como chamar o algoritmo. Cada classe derivada implementa o algoritmo como pretendido Estrutura genérica: 30 15