Histórico de revisões

Design Patterns

Histórico de revisões Data Versão Descrição Autor 15/1/2014 1.0 Finalização da primeira versão HEngholmJr

OBJETIVOS Fornecer uma visão geral sobre Design Patterns visando atingir os requisitos não funcionais dos projetos.

REQUISITOS NÃO FUNCIONAIS Adaptabilidade (Atender a novos propósitos sem grandes alterações no sistema, e.g., novos tipos de investimentos) Extensibilidade (Adição de novos serviços, extensão de serviços existentes sem impactos no restante do sistema) Manutenibilidade (Esforço exigido para localizar e reparar erros em um sistema ou para modificá-lo com o propósito de adaptá-lo a um novo ambiente,) Reusabilidade (Capacidade de reutilização de módulos do sistema em outras aplicações)

REQUISITOS NÃO FUNCIONAIS Performance (E.g., velocidade, taxas de transferências de dados, tempo de resposta) Escalabilidade (Capacidade do sistema manter o desempenho mesmo com o aumento do número de usuários) Confiabilidade (Exatidão, possibilidade de recuperação, poucos números de falhas,...) Usabilidade (Facilidade para que usuário aprenda a utilizar e de utilização do sistema)

Pattern Concept Conceitos do design orientado a Objetos Base dos padrões orientados a objetos: Coesão Encapsulamento Acoplamento Herança Composição Herança por interface Polimorfismo

Conceitos do design orientado a Objetos Coesão Coesão é o grau em que os métodos e atributos de uma classe estão relacionados a apenas uma finalidade no sistema Vantagens de alta coesão: Evita o efeito colateral de se alterar códigos não relacionados dentro de uma mesma classe Melhora a legibilidade, esclarecendo o papel exato da classe Facilita a criação de pequenos componentes reutilizáveis

Coesão Conceitos do design orientado a Objetos

Conceitos do design orientado a Objetos Encapsulamento A estrutura interna e comportamento de um objeto não deve ser exposto Esconder a informação é fundamental para o encapsulamento adequado, os dados do objeto devem ser mantidas em sigilo. Métodos de acesso e modificadores devem fornecer uma interface para acesso aos dados Vantagens Implementação de uma classe pode variar sem mudar sua interface Os desenvolvedores podem usar a classe sem conhecer todos os seus detalhes de implementação Impossibilidade de modificações inadequadas de atributo

Conceitos do design orientado a Objetos Encapsulamento

Conceitos do design orientado a Objetos Acoplamento Acoplamento é uma medida de como as classes dependentes estão no outras classes. Para reduzir o acoplamento: Ocultar a implementação das classes Utilizar interfaces de classes abstratas Reduzir o número de métodos na interface da classe Considere o acoplamento de todo o sistema, em vez de apenas entre as classes individuais

Acoplamento Conceitos do design orientado a Objetos

Conceitos do design orientado a Objetos Herança Herança garante que as subclasses herdem atributos compartilhados e métodos de uma superclasse Vantagens Evita a duplicação de código que é comum aos subtipos Organiza classes de acordo com a herança Desvantagens Força subclasses a herdar tudo de sua superclasse Alterações para a superclasse pode afetar a subclasse

Herança Conceitos do design orientado a Objetos

Conceitos do design orientado a Objetos Composição Construa objetos complexos a partir de objetos mais simples.

Conceitos do design orientado a Objetos Herança de interface Herança de interface é a separação da definição de uma interface de sua implementação. Similar aos dispositivos de hardware que implementam uma interface comum Pode fazer uma classe ser estendida sem ser modificada

Conceitos do design orientado a Objetos Polimorfismo Polimorfismo permite invocar operações de objetos específicos através de referências genéricas. Aspectos de polimorfismo Permite atribuir diferentes tipos de objetos em tempo de execução A implementação do método é determinada pelo tipo de objeto Vantagens Permite-lhe escrever código genérico que não depende de uma subclasse específica Permite codificar menos métodos porque um supertipo pode ser especificado como o tipo de parâmetro

Conceitos do design orientado a Objetos Polimorfismo - Exemplo

Exploração dos princípios de Design Orientado a Objetos A Gang of Four (Gamma, Helm, Johnson e Vlissides) indica 3 princípios de design orientado a objetos Favoreça a composição Programe para interfaces Realize o design prevendo mudanças

Exploração dos princípios de Design Orientado a Objetos Favoreça a composição Reuse funcionalidades através da composição ao invés de herança, reusabilidade caixa preta.

Exploração dos princípios de Design Orientado a Objetos Favoreça a composição No relacionamento de composição, um objeto pode conter de uma a várias instâncias de um outro objeto, sendo responsável pela sua criação e destruição. Uma pessoa poderá ter vários telefones que são armazenados na forma de um atributo no objeto Pessoa, chamado telefones. Este atributo na verdade é uma lista de objetos do tipo Telefone. Os objetos Telefone fazem são parte do objeto Pessoa, ou seja, um objeto Telefone (parte) fará parte somente de um único objeto Pessoa (todo). Quando o objeto Pessoa for destruído, seus objetos telefone também serão.

Exploração dos princípios de Design Orientado a Objetos Programe para a interface

Exploração dos princípios de Design Orientado a Objetos Realize o design prevendo mudanças Requisitos mudam, deste modo realize o design prevendo mudanças Utilize o princípio Open-Closed, entidades de software como as classes devem estar abertos para extensão e fechados para alteração.

Padrões de design

Design Patterns Soluções conhecidas para problemas conhecidos Cada padrão descreve um problema que ocorre repetidas vezes em nosso ambiente ou são bem conhecidos no mercado, descrevendo uma solução para esse problema, de uma maneira que você pode usá-la diversas vezes sem ter que encontrar a solução sozinho. Apenas use a solução, ele já existe, já foi testada centenas de vezes e é utilizada por milhares de sistemas.

Catálogos de Design Patterns - GoF Catálogo de Design Patterns Gang of Four (Primeira publicação de vários padrões de projeto, influenciou muitos padrões J2EE) - Catálogo J2EE Patterns GoF Gamma, Helm, Johnson, Vlissides

Elementos do Design Pattern Padrões de projeto incluem os seguintes elementos: Contexto - Situação em que o problema sendo abordado ocorre Problema - problema de design que o padrão está focado Forças - Requisitos que a solução deve satisfazer Solução e Estrutura - Solução para o problema Consequências - Vantagens e desvantagens de usar o padrão Padrões relacionados - padrões que são similares ou são usados para construir esse padrão

Notação do Design Pattern Pode ser representado utilizando-se UML através de diagramas de classe e sequencia. Class Diagram System Sequence Diagram Login DataHora +DataHora datahora:s tring data:s tring hora:s tring Menu host:s tring perfilusuario:int cousuario:int coempresa:int flaga dm Sistema:boolean +Menu -preenchemenu:void +retornaitems implesdemenu:string -retornacabecalho:string -retornaitemdemenuv ariositens:s tring -retornarodape:s tring AcessoBD +BeanD ec onexao Usuario loginui LoginServlet usuariocliente sistemaui 1: loginservlet 2: recuperadadosusuario 3: forward m enu:s tring opcoesdeavaliacoes:string opcoesdorh:string opcoesdeadministrador:string

Quando e onde aplicar Patterns Algumas literaturas sugerem a utilização de padrões pró-ativamente nos projetos Outras literatura sugerem a utilização de poucos padrões e refatoração dos mesmos no design do projeto De qualquer maneira, deve-se procurar um equilíbrio de design entre flexibilidade e simplicidade Depois de aprender design patterns, você provavelmente estará inclinado a resolver todos os problemas utilizando-se de padrões de design

Gang of Four (GoF) Patterns: Groups Padrões de comportamento: Descrevem como os objetos interagem e distribuem responsabilidades Padrões de criação: Fornecem formas mais robusta para a criação objetos Padrões estruturais: Padrões relacionados ao interrelacionamento entre objetos

Gang of Four Behavioral Patterns Strategy pattern: Encapsula uma família de algoritmos para uso intercambiável Command pattern: Encapsula solicitações de comandos entre objetos para execução pelo outro objeto Iterator pattern: Iterage coleções de maneira fracamente acoplada. Observer pattern: Fornece notificação de eventos através de um objeto observador

Gang of Four Behavioral Patterns Exemplo Strategy pattern: Necessidade de se alterar algoritmo de ordenação em tempo de execução. O objeto cliente seleciona qual tipo de sub-tipo da interface Strategy deve ser utilizado.

Gang of Four Behavioral Patterns Exemplo Strategy pattern: 1 public class CatalogSearchEngine { 2 3 private SortStrategy sorter; 4 5 public CatalogSearchEngine(SortStrategy ss) { 6 sorter = ss; 7 } 8 public ArrayList search() { 9 ArrayList list = //perform search 10 sorter.sort(list); 11 return list; 12 } 13 }

Gang of Four Behavioral Patterns Exemplo Strategy pattern: Strategy pattern interface: 1 public interface SortStrategy { 2 public void sort(arraylist al); 3 } First strategy implementation: 1 public class QuickSort implements SortStrategy { 2 public void sort(arraylist al) { 3 //implement Quick sort code 4 } 5 }

Gang of Four Behavioral Patterns

Gang of Four Creational Patterns Factory pattern: Cria objetos de uma classe ou suas subclasses através de uma chamada de método Abstract Factory pattern: Cria uma família de objetos através de uma interface única Singleton pattern: Restringe uma classe para uma instância globalmente acessível

Gang of Four Behavioral Patterns Exemplo Factory pattern: A classe cliente obtém uma referência genérica de fábrica para um objeto ConcreteFactory O cliente chama o método de fábrica createproduct na ConcreteFactory O método de fábrica retorna uma referência de um produto para uma nova ConcreteProduct Se o cliente obtém uma referência para uma ConcreteFactory diferente, ele receberá um ConcreteProduct diferente

Gang of Four Behavioral Patterns Exemplo JDBC API Factory pattern:

Gang of Four Behavioral Patterns Exemplo Factory pattern: O código para utilizar o pattern acima poderia ser: Factory f = new ConcreteFactory1(); Menu m = f.createmenu ();

Gang of Four Behavioral Patterns Exemplo Singleton pattern Existem classes que devemos ter apenas uma única instância da mesma A única instância de uma classe deve ser facilmente acessada de diferentes partes da aplicação A única maneira de proteger a criação de um único objeto de uma classe é escondendo o construtor da mesma

Gang of Four Structural Patterns Façade pattern: Fornece uma interface simplificada para um subsistema Proxy pattern: Fornece um objeto intermediário que controla o acesso a um outro objeto. Adapter pattern: Permite chamadas para utilização um objeto que tem uma interface incompatível Composite pattern: Compõe objetos em estruturas parte-todo de estruturas tipo árvore. Decorator pattern: Anexa dinamicamente novas funcionalidades em um objeto.

Gang of Four Structural Patterns

Gang of Four Structural Patterns

Gang of Four Structural Patterns

Gang of Four Structural Patterns

Gang of Four Structural Patterns

Design Pattern Selection A seleção do padrão deve ser baseada em semelhanças entre o contexto, o problema, e o problema do design Múltiplos padrões podem ser usados para resolver um problema particular

Padrões de arquitetura

Model View Controller (MVC) Pattern Model View Controller (MVC) é um padrão de arquitetura Encontrado em muitos lugares, incluindo no Java Foundation Classes / Swing (JFC / Swing) API Separa o gerenciamento da apresentação da lógica do aplicativo Útil em aplicações onde a interface do usuário pode mudar freqüentemente MVC pode ser adaptado para aplicações Web

Aplicando o MVC Pattern Separa apresentação do estado e comportamento. Interfaces de usuário e de processamento de negócios mudam frequentemente de forma independente e alguns sistemas têm múltiplas interfaces de usuário A interface de usuário deve ser dissociada dos dados e do processamento Você pode exibir as mesmas informações em diferentes pontos de vista Os pontos de vista podem precisar refletir imediatamente as alterações do modelo de dados Os dados do modelo devem responder imediatamente às mudanças iniciadas nas interfaces

(Model 1/Model 2)

Aplicando o padrão MVC O padrão Model View Controller divide o sistema em três conjuntos de componentes: Model - Contém os dados de negócios, processamento e regras. O modelo não deve ter quaisquer detalhes sobre a interface do usuário View - Exibe uma interface gráfica de usuário (GUI), contendo os componentes do modelo de dados para o usuário e, normalmente, passa eventos GUI aos componentes do controller Controller - Aceita pedidos do usuário, invoca o processamento sobre os componentes do modelo, e determina qual componente da camada View deve ser exibido

Overview do pattern MVC * << Envia input do usuário * Controler -View -Model +updatemodel() +chooseview() * Seleciona >> * * View User controls * Updates >> Model * << Uses * State Data

J2EE Pattern Catalog

J2EE Pattern Catalog O catálogo de padrões J2EE são agrupados em três níveis: Integration tier Business tier Presentation tier

J2EE Integration Tier Patterns Service Activator - Permite que um cliente de forma assíncrona invocar um componente EJB, usando o Java Message Service (JMS) API Data Access Object - Isola banco de dados de código específico em classes que expõem uma interface de negócios Domain Store - Cria um mecanismo de persistência robusto que é transparente para os objetos de negócios sem usar os beans de entidade Web Service Broker - Faz serviços empresariais disponíveis como serviços web

Exemplo DAO Design Patterns

J2EE Business Tier Patterns Service Locator - Elimina a necessidade de um cliente plataforma J2EE estar ciente do Java Naming and Directory Interface (JNDI) API na aquisição de componentes de negócios Session Façade - Fornece a camada de apresentação com uma interface simples para acessar a camada de negócios Business Delegate - Fornece acesso flexível aos componentes camada de negócios Transfer Object - Reduz o número de chamadas de método remoto, retornando vários valores em um objeto

J2EE Business Tier Patterns Application Service - Centraliza a lógica de negócios entre services facades e os objetos de negócios Businness Object - Separa dados de negócio da lógica de negócios e workflow lógico Transfer Object Assembler - Monta objeto de transferência de dados de múltiplos objetos de negócios Composite Entity - Wraps um número de objetos relacionados em uma única entidade Value List Handler - Fornece um mecanismo eficiente para a execução de consultas que pode retornar um grande número de objetos e navegar através dos resultados

J2EE Presentation Tier Patterns Interceptando Filter - Gerencia de processamento de pré e pósprocessamento de um pedido do cliente Front Controller - Fornece um mecanismo para gerenciamento centralizado de solicitações de usuários Application Controller - Separa a invocação da gestão e despacho da view do componente front controller Context Object Passa os dados de objetos de contexto específico, sem passar esses objetos

J2EE Presentation Tier Patterns View Helper - Fatores fora de recuperação de conteúdo necessárias para construir a visão Composite View - Constrói uma view a partir de diferentes views Dispatcher View - Combina a Front Controller e padrões View Helper Service to Worker - Similar ao padrão Dispatcher View, exceto que o controlador frontal tem mais responsabilidade para seleção da visão e invocação do processo de negócios

Front Controller Pattern Client Front controler Page controler View (JSP) Model (Beans) HTTP request Common functions Update Forward Update Forward HTTP response Fornece um único local que encapsula o processamento de solicitação comum