©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/65 Padrões de Projeto

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE2/65 Objetivos n Explicar:  O que é um padrão de projeto  Alguns padrões que já foram identificados no desenvolvimento de software  Como aplicar padrões de projeto durante o desenvolvimento de software  Os benefícios e dificuldades que podem surgir quando usamos padrões de projeto

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE3/65 Motivação n Projetar software OO reusável e de boa qualidade é difícil  Mistura de específico + genérico  Impossível acertar da primeira vez n Projetistas experientes usam soluções com as quais já trabalharam no passado n Padrões de projeto  Uso sistemático de: ènomes, èexplicações, èe avaliações n Durante a última década, uma “comunidade de padrões” foi desenvolvida

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE4/65 Algumas definições n “Cada padrão descreve um problema que ocorre freqüentemente em seu ambiente, e então descreve o núcleo de uma solução para o problema, de maneira que você possa usar esta solução um milhão de vezes, sem fazê-la do mesmo jeito duas vezes.” Christopher Alexander (Arquiteto e Urbanista), 1977 n “Um padrão é a abstração de uma forma concreta que ocorre muitas vezes em contextos não arbitrários específicos.” Riehle and Zullighoven, 1996 n “Resolve um problema. É um conceito provado. A solução não é óbvia. Descreve um relacionamento. Os padrões têm um componente humano significativo.” Coplien 1996.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE5/65 Características dos Padrões de Projeto de Software n Algo comprovado que captura e comunica os conhecimentos das melhores práticas n Descoberto, não inventado n Soluções Sucintas e de Fácil Aplicação  Capturam, de forma sucinta e facilmente aplicável, soluções de projeto de programas de computador que foram desenvolvidas e evoluíram com o passar do tempo n Soluções Exaustivamente Refinadas  Resultados de um longo processo de projeto, re-projeto, teste e reflexão sobre o que torna um sistema mais flexível, reusável, modular e compreensível n Soluções Compartilhadas  Construídas em grupo  Através do uso de um vocabulário comum

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE6/65 Outros Tipos de Padrões n Padrões de Análise:  Descrevem grupos de conceitos que representam construções comuns na modelagem do domínio. Estes padrões podem ser aplicáveis em um domínio ou em muitos n Padrões de Arquitetura:  Descrevem a estrutura e o relacionamento dos componentes de um sistema de software n Padrões de Processo

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE7/65 Catálogos e Linguagens de Padrões n Um catálogo de padrões é um grupo de padrões que estão relacionados de uma certa forma e podem ser usados juntos ou independentemente n Os padrões numa linguagem de padrões estão relacionados, e trabalham juntos para solucionar problemas num domínio específico  um conjunto de padrões que trabalham juntos para solucionar um grande problema

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE8/65 Princípios Presentes nos Padrões n Abstração n Encapsulamento n Proteção de informação n Modularização n Separação de conteúdos n Acoplamento e coesão n Suficiência, completude e primitividade n Separação entre interface e implementação n Único ponto de referência n Dividir para conquistar

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE9/65 Anti-Padrões n São uma maneira de documentar soluções recorrentes que não tiveram sucesso èPodem também incluir soluções re-trabalhadas que sejam efetivas

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE10/65 Elementos para Documentação de um Padrão de Projeto Nome: Resume em uma ou duas palavras: o problema, as soluções e conseqüências do uso do padrão. Deve ser facilmente lembrado, reflete o conteúdo do padrão. Problema: Descreve quando aplicar o padrão. Explica o problema e seu contexto. Sintomas e condições. Solução: Elementos que constituem o design, seus relacionamentos, responsabilidades e colaboradores. Conseqüências: Resultados e compromissos decorrentes da aplicação do padrão. Impactos sobre a flexibilidade, extensibilidade, portabilidade ou desempenho do sistema.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE11/65 Outros Elementos para Documentação n Um exemplo de uso n A razão que justifica a solução escolhida n Padrões relacionados n Uso conhecido do padrão n Lista de outros nomes para o padrão n Amostra de código em uma linguagem de programação

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE12/65 Tipos de Padrões de Projeto n Padrões de Projeto foram introduzidos para a comunidade OO através de  Gamma E., et al, Design Patterns, Addison-Wesley, 1994 n Eles categorizaram (23) padrões em três tipos:  Estruturais (7)  Criacionais (5)  Comportamentais (11) n divididos em 2 escopos:  Classe  Objeto

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE13/65 Escopo n Classe  Relacionamentos entre classes e suas subclasses  Não é preciso executar nenhum código para determinar o uso dos padrões  Estáticos: fixos em tempo de compilação n Objeto  Confia em ponteiros de objetos  Dinâmicos: relacionamentos entre objetos podem ser alterados em tempo de execução

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE14/65 Detalhamento dos Tipos de Padrões n Estruturais  Tratam de compor classes e objetos para formar estruturas grandes e complexas  Associados à maneira como classes e objetos são organizados estruturalmente  Oferecem formas efetivas para usar conceitos OO como herança, agregação e composição  Focam na abstração da estrutura

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE15/65 Detalhamento dos Tipos de Padrões n Criacionais  Associados ao processo de criação de objetos  Tornam um sistema independente de como seus objetos são criados, compostos e representados n Comportamentais  Tratam de algoritmos e como atribuir responsabilidades entre objetos  Associados à maneira que objetos e classes distribuem suas responsabilidades para realizar uma tarefa  Focam na abstração do comportamento

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE16/65 Alguns Exemplos n Padrão Composite (estrutural) n Padrão Singleton (criacional) n Padrão State (comportamental)

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE17/65 Padrão Estrutural: Composite n Nome: Composite n Problema:  Se existe um requisito para representar hierarquias todo- parte, então ambos objetos (todo e parte) oferecem a mesma interface para objetos cliente. n Contexto:  Numa aplicação tanto o objeto que contém quanto o que é componente devem oferecer o mesmo comportamento. èObjetos cliente devem ser capazes de tratar objetos compostos ou componentes do mesmo jeito.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE18/65 Padrão Estrutural: Composite n Forças:  O requisito que os objetos, tanto composto como componente, ofereçam a mesma interface, sugere que eles pertençam à mesma hierarquia de herança. èIsto permite que operações sejam herdadas e redefinidas com a mesma assinatura (polimorfismo).  A necessidade de representar hierarquias todo-parte indica a necessidade de uma estrutura de agregação

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE19/65 Padrão Estrutural: Composite n Solução : Combinar hierarquias de herança e agregação.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE20/65 Padrão Estrutural: Composite n Solução:  Ambas subclasses, Leaf e Composite, têm uma operação redefinida usando polimorfismo anOperation(). èNa classe Composite esta operação redefinida invoca a operação relevante a partir de seus componentes usando um loop.  A subclasse Composite também tem operações adicionais para gerenciar a hierarquia de agregação, então os componentes podem ser adicionados ou removidos.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE21/65 Exemplo do Padrão Composite: Graphical drawing package Graphic draw getChild removeGraphic addGraphic CompositeGraphic draw getChild removeGraphic addGraphic Line draw Rectangle draw Circle draw Client 0..*

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE22/65 Outro Exemplo do Padrão Composite: Campanhas de Midia

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE23/65 Padrão Composite: Exemplo de Uso n Diretórios e arquivos em um sistema de arquivos

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE24/65 Padrão de Criação: Singleton n Nome: Singleton n Problema: Como pode ser construída uma classe que só pode ter uma única instância e que pode ser acessada globalmente dentro da aplicação? n Contexto: Em algumas aplicações, uma classe deve ter exatamente uma instância.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE25/65 Padrão de Criação: Singleton n Forças:  Uma abordagem para tornar um objeto acessível globalmente é colocá-lo como uma variável global.  Outra abordagem é não criar uma instância de objeto em nenhum lugar, mas usar operações e atributos de classe (chamados ‘static’ em C++ e Java).

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE26/65 Padrão de Criação: Singleton n Solução:  Criar uma classe com uma operação de classe (ou estática, ex: Java, C++) getInstance(), que: èQuando a classe é acessada pela primeira vez, a instância do objeto é criada e retornada para o cliente. èNos acessos subseqüentes a getInstance() nenhuma instância adicional é criada, mas a identidade do objeto existente é retornada.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE27/65 Padrão de Criação: Singleton Singleton static uniqueInstance singletonData getInstance() getSingletonData() singletonOperation() return uniqueInstance

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE28/65 Padrão de Criação: Singleton n Vantagens:  Oferece acesso controlado à única instância do objeto, pois a classe Singleton encapsula a instância.  A classe Singleton pode ter subclasses. Pode-se determinar que subclasses são instanciadas quando a classe Singleton é acessada pela primeira vez.  Uma variação do padrão pode ser usada para criar um número específico de instâncias, se for requerido.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE29/65 Padrão Singleton: Um Exemplo de Uso n O sistema de gerenciamento de campanhas de uma empresa precisa guardar informações a respeito da empresa. n Estas informações só devem ser guardadas em um único lugar dentro da aplicação, mas serão usadas por diferentes objetos. n Quando um objeto cliente precisa acessar o objeto Company, pode enviar a mensagem getCompanyInstance() e receber o identificador do objeto na resposta. n O objeto cliente pode então enviar uma mensagem getCompanydetails() para o objeto Company

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE30/65 Padrão Singleton: Exemplo

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE31/65 Padrão Singleton: Exemplo n Mas a companhia opera como uma empresa separada em cada país  diferentes detalhes registrados da empresa para cada país n A classe Company só é instanciada uma vez. Ela é acessível globalmente. n Diferentes subclasses de Company são instanciadas quando necessário, dependendo das circunstâncias em tempo de execução.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE32/65 Padrão Singleton: Exemplo

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE33/65 Padrão Comportamental: State n Nome: State n Problema: Um objeto exibe um comportamento diferente quando seu estado interno muda, fazendo o objeto parecer ter mudado a classe em tempo de execução. n Contexto: Ema algumas aplicações um objeto pode ter o comportamento complexo que seja dependente do seu estado. A resposta para uma mensagem específica varia de acordo com o estado do objeto.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE34/65 Padrão Comportamental: State n Forças:  O objeto tem comportamento complexo que deve ser dividido em elementos menos complexos. Uma ou mais operações têm comportamento que variam de acordo com o estado do objeto.  Tipicamente a operação teria muitas sentenças condicionais dependentes do estado.  Uma abordagem é ter operações públicas diferentes para cada estado, mas objetos cliente precisariam saber o estado do objeto para poderem chamar a operação adequada

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE35/65 Padrão Comportamental: State n Solução:  Separar o estado dependente do comportamento do objeto original e alocar este comportamento para um série de outros objetos, um para cada estado.  Estes objetos estado têm apenas responsabilidade relacionadas ao comportamento do respectivo estado.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE36/65 Padrão Comportamental: State Context operation( ) State {abstract} operation( ) ConcreteStateA ConcreteStateB operation( )

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE37/65 Participantes do Padrão State Context define a interface de interesse para clientes. Mantém uma instância de uma subclasse ConcreteState que define o estado corrente State define uma interface para encapsulamento do comportamento associado com um estado específico do Contexto Subclasses ConcreteState cada subclasse implementa um comportamento associado com um estado do Contexto

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE38/65 Padrão Comportamental: State n Vantagens:  O comportamento do estado é localizado e o comportamento para diferentes sub-estados é separado. Isto facilita qualquer modificação do comportamento do estado, em particular a adição de estados extra.  Transições de estado são explícitas. O objeto estado, que está ativo, indica o estado atual do objeto Contexto.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE39/65 Padrão Comportamental: State n Desvantagens:  O objeto Estado pode ser criado ou removido quando o objeto Context muda o estado, introduzindo assim um overhead no processamento.  O uso do padrão State introduz pelo menos uma mensagem extra, a mensagem da classe Context para classe State, adicionando assim mais overhead no processamento.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE40/65 Padrão State: Um Sistema de Biblioteca LoanStatus {abstract} CheckOut Available OnLoan CheckOut Copy CheckOut Available:: CheckOut (book; user) //Check out book to a user OnLoan:: CheckOut (book; user) //Error: ‘Book already out’ As subclasses concretas definem o método de acordo com o estado que elas representam

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE41/65 Padrão State: Exemplo de Campanhas

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE42/65 Questões Relativas ao Uso de Padrões n Existe algum padrão que trata um problema similar? n O contexto do padrão é consistente com o problema real? n As conseqüências do uso de padrão são aceitáveis? n O padrão tem uma solução alternativa que pode ser mais aceitável? n Existe uma solução mais simples? n Existem algumas restrições que sejam impostas pelo ambiente de software que está sendo usado?

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE43/65 Problemas com o Catálogo de Padrões n Armazenamento, busca e manutenção da documentação de padrões n Padrões colecionados num catálogo precisam ser agrupados n Projetistas descobrindo novos padrões precisam considerar onde o seu novo padrão se encaixa no catálogo n Publicação de padrões disponíveis  Todos os usuários precisam ser atualizados sobre o conteúdo do catálogo

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE44/65 Perigos do Uso de Padrões n O uso de padrões de uma maneira descontrolada pode originar projetos sobre-carregados. n Desenvolvedores:  Precisam de tempo para entender os catálogos de padrões relevantes  Precisam de fácil acesso a catálogos relevantes  Precisam ser treinados no uso de padrões

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE45/65 O Catálogo de Padrões de Gamma

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE46/65 Padrões de Criação: Objeto n Singleton  Garante que uma classe tenha apenas uma única instância, e oferece um ponto global para acessá-la. n Fábrica Abstrata (Abstract Factory)  Oferece uma interface para criar famílias de objetos relacionados sem especificar suas classes concretas. n Construtor (Builder)  Separa a construção de um objeto complexo de sua representação, então o mesmo processo de construção pode criar diferentes representações. n Protótipo (Prototype)  Especifica os tipos de objetos para criar usando uma instância prototípica, e cria novos objetos copiando deste protótipo.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE47/65 Padrões de Criação: Classe n Método Factory  Define uma interface para criação de um objeto, mas deixa a subclasse decidir que classe instanciar.  Permite a classe retardar a instanciação da subclasse.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE48/65 Padrões Estruturais: Objeto n Adaptador (Adapter)  Converte a interface de uma classe em outra interface que os clientes esperam. n Ponte (Bridge)  Desacopla uma abstração da sua implementação, as duas podem variar independentemente (herança em tempo de execução) n Composite  Compõe objetos em estruturas para representar hierarquias todo-parte. Permite que clientes tratem tanto os objetos individuais quanto as composições de objetos uniformemente.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE49/65 Padrões Estruturais: Objeto n Decorador (Decorator)  Anexa responsabilidades adicionais para um objeto dinamicamente. n Fachada (Façade)  Oferece uma interface unificada para um conjunto de interfaces de um subsistema. n Peso Mosca (Flyweight)  Usa compartilhamento para apoiar eficientemente um grande número de objetos de fina granularidade. n Proxy  Oferece um ponto de acesso para outro objeto controlar o acesso.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE50/65 Padrões Estruturais: Classe n Adaptador (Adapter)  Converte a interface de uma classe para outra interface que os clientes esperam. n Base de Template (Template Base)  Usa classes base do template para especificar associações.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE51/65 Padrões Comportamentais: Objeto n Cadeia de Responsabilidade (Chain of Responsability)  Evita o acoplamento do emissor de um pedido ao seu receptor n Observador (Observer)  Quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE52/65 Padrões Comportamentais: Objeto (cont.) n Iteração (Iterator)  Oferece uma maneira para acessar os elementos de um objeto agregado seqüencialmente sem expor a sua representação. n Mediador (Mediator)  Define um objeto que encapsula a forma como um conjunto de objetos interagem entre si.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE53/65 Padrões Comportamentais: Objeto (cont.) n Comando  Encapsula a requisição como um objeto. n “Memento”  Captura e externaliza um estado interno do objeto para que este estado possa ser recuperado depois. n Estado (State)  Permite que um objeto altere seu comportamento quando seu estado interno muda.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE54/65 Padrões Comportamentais: Objeto (cont.) n Estratégia  Define uma família de algoritmos, encapsula cada um, e torna-os inter-cambiáveis. n Visitante  Representa uma operação a ser realizada para os elementos da estrutura de um objeto.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE55/65 Padrões Comportamentais: Classe n Interpretador  Dada uma linguagem, define uma representação para sua gramática com um interpretador que usa a representação para interpretar sentenças na linguagem. n Template de método  Permite que subclasses redefinam certos passos de um algoritmo sem alterar a estrutura do algoritmo.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE56/65 Padrões de Projeto para Arquitetura em Camadas

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE57/65 Padrão Façade n Intenção  Prover uma interface unificada para o conjunto de interfaces de um subsistema. Define uma interface de alto nível que faz um subsistema mais fácil de usar. n Motivação  Estruturar um sistema em subsistemas contribui para reduzir sua complexidade. A dependência entre subsistemas pode ser minimizada através do uso de um objeto Fachada, o qual provê uma interface única e uniforme para as diversas funcionalidades de um subsistema.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE58/65 Padrão Façade: Estrutura e Participantes Façade subsystem classes Client

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE59/65 Padrão Façade: Aplicabilidade n Use o Padrão Façade quando:  Você quer prover uma interface simplificada para um subsistema complexo. Um Façade pode prover uma visão simples do subsistema, suficiente para a maioria dos clientes  Existem muitas dependências entre clientes e classes da implementação. O Façade reduz esta dependência e promove independência e portabilidade  Você quer criar sistemas em camadas. Um Façade provê o ponto de entrada para cada camada (nível) do subsistema.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE60/65 Padrão Façade: Conseqüências n Promove acoplamento fraco entre o subsistema e seus clientes n No entanto, não evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE61/65 Padrão Persistent Data Collections (PDC) n Nome: PDC n Problema: Como melhorar os níveis de manutenção e reuso quando usando mecanismos de persistência em aplicações orientadas a objeto? n Contexto: Durante o desenvolvimento de aplicações orientadas a objeto que utilizam mecanismos de persistência, através de APIs (Application Programming Interfaces) específicas, é possível que o código gerado misture a lógica da aplicação com os mecanismos de persistência, dificultando assim a manutenção e o reuso.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE62/65 Padrão PDC n Forças:  Desenvolvedores devem poder endereçar os aspectos de negócio de uma organização independente das operações de persistência.  O mecanismos de persistência podem mudar durante o período de vida da aplicação.  Classes de negócio podem ser usadas por outras aplicações.  O mecanismo de persistência deve lidar de forma eficiente com a habilitação de conexões com o banco de dados e com o gerenciamento de transações.  A performance do sistema não deve ser afetada.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE63/65 Padrão PDC n Solução:  Separar as classes de análise em duas categorias: èClasses descrevendo os objetos de negócio. èClasses para a manipulação e armazenamento de dados, com código específico para o tratamento de persistência.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE64/65 Padrão PDC BusinessCollection specificSystemService() > IBusinessData insert() remove() update() search() Façade PersistentDataCollection insert() remove() update() search() BusinessBasic > IPersistenceMechanism beginTransaction() connect() commit() PersistenceMechanism beginTransaction() connect() commit() 1..* 0..*

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE65/65 Leituras Adicionais n Gamma E, Helm R, Johnson R and Vlissides J. Design Patterns: Elements of Reusable Object- Oriented Software. Addison-Wesley n n bin/wikic/wikic?JavaAWT bin/wikic/wikic?JavaAWT n n eaPublications/PersistentDataCollectionsPLOP2001. pdf eaPublications/PersistentDataCollectionsPLOP2001. pdf