Design Patterns (Padrões de Projeto) Jobson Ronan {jrjs@cin.ufpe.br}

Objetivos 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

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

Definições “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 “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 “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.

Características Algo comprovado que captura e comunica os conhecimentos das melhores práticas Descoberto, não inventado 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 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 Soluções Compartilhadas Construídas em grupo Através do uso de um vocabulário comum

Outros Tipos de Padrões 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 Padrões de Arquitetura: Descrevem a estrutura e o relacionamento dos componentes de um sistema de software Padrões de Processo

Catálogos e Linguagens de Padrões 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 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

Princípios Presentes nos Padrões Abstração Encapsulamento Proteção de informação Modularização Separação de conteúdos Acoplamento e coesão Suficiência, completude e primitividade Separação entre interface e implementação Único ponto de referência Dividir para conquistar

Anti-Padrões 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 “Gambiarras Clássicas”

Elementos para Documentação 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.

Outros Elementos Um exemplo de uso A razão que justifica a solução escolhida Padrões relacionados Uso conhecido do padrão Lista de outros nomes para o padrão Amostra de código em uma linguagem de programação

Tipos de Padrões de Projeto Padrões de Projeto foram introduzidos para a comunidade OO através de Gamma E., et al, Design Patterns, Addison-Wesley, 1994 Eles categorizaram (23) padrões em três tipos: Estruturais (7) Criacionais (5) Comportamentais (11) divididos em 2 escopos: Classe Objeto

Escopo Classe Objeto Relacionamentos entre classes e suas subclasses Não é preciso executar nenhum código para determinar ouso dos padrões Estáticos: fixos em tempo de compilação Objeto Confia em ponteiros de objetos Dinâmicos: relacionamentos entre objetos podem ser alterados em tempo de execução

Detalhamento dos Tipos de Padrões Estruturais Tratam de compor classes e objetos para formar estruturas grandes e complexas Associados à maneira como classes e objetos sãoorganizados estruturalmente Oferecem formas efetivas para usar conceitos OO comoherança, agregação e composição Focam na abstração da estrutura

Detalhamento dos Tipos de Padrões Criacionais Associados ao processo de criação de objetos Tornam um sistema independente de como seus objetos são criados, compostos e representados 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

Alguns Exemplos Padrão Composite (estrutural) Padrão Singleton (criacional) Padrão State (comportamental)

Padrão Estrutural: Composite Nome: Composite Problema: Se existe um requisito para representar hierarquias todo-parte, então ambos objetos (todo e parte) oferecem a mesma interface para objetos cliente. 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.

Padrão Estrutural: Composite Forças: O requisito que os objetos, tanto composto como componente, ofereçam a mesma interface, sugere que elespertenç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

Padrão Estrutural: Composite Solução : Combinar hierarquias de herança e agregação.

Padrão Estrutural: Composite 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.

Exemplo: Campanhas de Midia

Exemplo: Sistema de Arquivos

Padrão de Criação: Singleton Nome: Singleton 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? Contexto: Em algumas aplicações, uma classe deve ter exatamente uma instância.

Padrão de Criação: Singleton 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).

Padrão de Criação: Singleton 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.

Padrão de Criação: Singleton 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.

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

Padrão Singleton: Exemplo

Padrão Comportamental: State Nome: State 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. Contexto: Ema algumas aplicações um objeto pode ter o comportamento complexo que seja dependente do seu estado. A resposta para uma mensagem

Padrão Comportamental: State 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

Padrão Comportamental: State Solução: Separar o estado dependente do comportamento do objeto original e alocar este comportamento para um série deoutros objetos, um para cada estado. Estes objetos estado têm apenas responsabilidade relacionadas ao comportamento do respectivo estado.

Padrão Comportamental: State

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 associadocom um estado do Contexto

Padrão Comportamental: State 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, queestá ativo, indica o estado atual do objeto Contexto.

Padrão Comportamental: State 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.

Padrão State: Um Sistema de Biblioteca As subclasses concretas definem o método de acordo com o estado que elas representam

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

Problemas com o Catálogo de Padrões Armazenamento, busca e manutenção da documentação de padrões Padrões colecionados num catálogo precisam ser agrupados Projetistas descobrindo novos padrões precisam considerar onde o seu novo padrão se encaixa no catálogo Publicação de padrões disponíveis Todos os usuários precisam ser atualizados sobre o conteúdo do catálogo

Perigos do Uso de Padrões O uso de padrões de uma maneira descontrolada pode originar projetos sobre-carregados. 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

Padrões de Projeto para Arquitetura em Camadas Padrão Façade Padrão Persistent Data Collections (PDC)

Padrão Façade Intenção Motivaçã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. 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.

Padrão Façade: Estrutura e Participantes

Padrão Façade: Aplicabilidade 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.

Padrão Façade: Conseqüências Promove acoplamento fraco entre o subsistema e seus clientes No entanto, não evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem.

Padrão Persistent Data Collections (PDC) Nome: PDC Problema: Como melhorar os níveis de manutenção e reuso quando usando mecanismos de persistência em aplicações orientadas a objeto? 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.

Padrão PDC Forças: A performance do sistema não deve ser afetada. 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.

Padrão PDC 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.

Padrão PDC

Design Patterns (Padrões de Projeto) Jobson Ronan {jrjs@cin.ufpe.br}