Padrões de Projeto Aplicações empresariais são complexas

Slides:



Advertisements
Apresentações semelhantes
Soluções elegantes para problemas recorrentes
Advertisements

Padrão de Projeto Iterator
PADRÕES DE PROJETO..
Modelagem de Software Orientado a Objetos
Engenharia de Software
Design Patterns Builder Pattern
Projeto de Sistemas de Software
Padrão de Projeto Memento
Projeto de Sistemas de Software
Projeto de Sistemas de Software
1 Introdução aos padrões de projeto (GoF) Conceitos preliminares –Mecanismos de herança –Princípio de Substituição de Liskov –Acoplamento concreto x Acoplamento.
Eduardo Bezerra Padrões GoF Eduardo Bezerra
Template Method Intenção: definir o esqueleto de um algoritmo em uma operação, postergando (delegando) a definição de alguns passos desse algoritmo para.
Chain of Responsibility
Padrões - introdução O que é um padrão?
Fundação Aplicações de Tecnologias Críticas - Atech
Design Pattern e a Reusabilidade de Software
Padrão de Construção Factory Method
Introdução a Arquitetura Orientada a serviços
Design Patterns Projeto de Sistemas de Software.
Fundamentos da Engenharia de Software
Projeto de Sistemas de Software
Linguagens Orientadas a Objeto
Integração com Banco de Dados
Gerência de Configuração - GC
Arquitetura de Sistemas Distribuídos
Rodrigo Cândido da Silva Instrutor VOffice / Globalcode
SISTEMAS DISTRIBUIDOS Aula 4
Padrões de Projeto These slides complement the E-book, Programming in the Large With Design Patterns available on both Kindle and Nook. Additional supporting.
Design Pattern (Padrões de Projeto)
Processos.
1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra Outubro/2005.
Introdução a JEE Marco A. S. Reis Arquiteto de Software Abril/2011.
Padrões de Projeto.
Introdução Padrões de Projeto
Padrões de Interação com o Usuário
Design Patterns (Padrões de Projeto)
Padrão de Projeto Iterator Projeto de Sistemas de Software Thiago Pinheiro de Araújo.
Trabalho Final de Padrões de Projeto
Padrões de Design Toacy Cavalcante de Oliveira. 2 April 20, 2015 Problema.
Padrões de Projeto Abstract Factory.
Padrões de Projeto.
Design Patterns A adoção dos padrões terá um efeito profundo e duradouro sobre a forma de escrevermos programas Ward Cunningham e Ralph Johnson.
Padrões de Projeto de Software Orientado a Objetos
1 Padrões: Composite (p. 163) Objetivo: compor objetos em estruturas de árvores para representar relações de parte/todo. “Composite” permite tratar objetos.
Padrões de projeto M.Sc. Sílvio Bacalá Jr..
1 Design Patterns Israel Rios. 2 Origens A idéia de padrões de projeto não teve origem na ciência da computação Christopher Alexander A Pattern Language:
Padrão Composite Definição
Jobson Ronan Padrões GoF Jobson Ronan
Detalhamento dos Padrões - Estrutura
1 - Introdução a Padrões de Projeto
Projeto Supervisionado no Desenvolvimento de Aplicações Profissionais na Web Servidores.
Padrões de Projetos Professora Lucélia. Conceitos É uma solução conhecida para um problema comum São técnicas que nos dão uma boa solução para determinados.
Padrões de Projetos Orientados a Objetos I Wolley W. Silva.
PADROES DE PROJETO PROF. OSIEL MARLON. PADRÕES DE PROJETO INTRODUÇÃO Padrões de projeto têm emergido como uma das mais promissoras abordagens para a melhoria.
Padrões de Projeto. O que são?  Soluções provenientes de diversos projetos e utilizados por diversos programadores;  Documentados em catálogos como.
Desenvolvimento WEB II Professora: Kelly de Paula Cunha Apresentação baseada no material didático elaborado pelo Prof. Pasteur Ottoni de Miranda Junior.
Introdução POO Thiago Medeiros Sistemas de Informação Definição: Sistemas de Informação é uma combinação de pessoas, dados, processos, redes de.
Padrões de Projeto de Criação Padrões de Projeto Orientados a Objetos Prof a. Danielle Martin Universidade de Mogi das Cruzes.
1 Introdução aos Padrões de Projetos (na prática) Créditos: Lúbia Vinhas Hazel Carvalho Crato Adaptações: Prof. Nécio de Lima Veras.
Aplicativos para Web MVC Prof. Odair Indena Jr.
1 Padrões de Projeto de Software Orientado a Objetos Programação Orientada a Objetos Prof. Fabio Kon - IME/USP.
1 Introdução aos Padrões de Projetos Créditos: Prof. Fabio Kon - IME/USP Adaptações: Prof. Nécio de Lima Veras.
Introdução a Padrões de Projeto Padrões de Projeto Orientado a Objetos Profa. Danielle Martin Universidade de Mogi das Cruzes.
Programação Orienta a Objetos (SI) Análise e Projetos de Sistemas (LCC) 1 - Introdução a Padrões de Projeto Eduardo de Lucena Falcão.
Introdução a Padrões de Projeto Padrões de Projeto Orientado a Objetos Profa. Danielle Martin Universidade de Mogi das Cruzes.
Testes de Unidade. 2 Pauta Testes de Unidade; Testes de Unidade; Desenvolvimento orientado a testes; Desenvolvimento orientado a testes; Testes unitários.
Padrões de Projeto Aula 15 – Padrão Command. PADRÃO COMMAND Encapsulando a chamada de métodos com o padrão Command. 2.
Padrões Comportamentais Preocupam-se com algoritmos e a atribuição de responsabilidades entre objetos. Descrevem padrões de comunicação entre os objetos.
Padrões de Projeto.
Transcrição da apresentação:

Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois princípios: utilizar abordagens comprovadamente funcionais e antecipar necessidades futuras. Em ambos os casos, existem técnicas comuns que transcendem um sistema individual. Essas técnicas são conhecidas como design patterns.

Padrões de Projeto (Design Patterns) Definição “Os padrões de projeto são descrições de objetos que se comunicam e classes que são customizadas para resolver um problema genérico de design em um contexto específico" A idéia dos design patterns é capturar experiências comprovadamente corretas em desenvolvimento de software e ajudar a promover a prática de projeto correto. Cada pattern trabalha com um problema específico e recorrente no projeto ou implementação de softwares.

Design Patterns (Vantagens) Esses patterns podem ser usados repetidas vezes, facilitando a incorporação da experiência de desenvolvimentos anteriores em novos projetos; Patterns também fornecem uma linguagem comum para a discussão de arquitetura de software em um nível mais elevado; Diminuem o tempo e o custo de projeto;

GOF Design Patterns Em 1994, liderados por Erich Gamma a GOF (Gang of Four) - Erich Gamma, Richard Helm, Ralph Johnson a John Vlissides publicaram o livro que deu origem à onda dos Patterns na área de informática, Design Patterns: Elements of Reusable Object-Oriented Software. O primeiro catálogo bem descrito sobre patterns de projeto para programas orientados a objeto. Neste livro eles apresentam 23 padrões de projeto úteis.

Classificação dos Design Patterns Os patterns foram classificados pelo GOF de duas formas por proposta e por escopo; A mais famosa é a por proposta, onde os patterns são classificados como de criação, comportamento e estrutura; Os padrões de criação são aqueles que abstraem o processo de instanciação de objetos. Eles são ligados as instâncias e definem quais classes devem ser instanciadas ou não. Os padrões de estrutura são aqueles que se ocupam da alteração da estrutura do de objetos e classes no que diz respeito a sua composição no sistema. Os padrões de comportamento são aqueles que cuidam do controle do comportamento de classes ou objetos. São patterns dinâmicos que se ocupam de como a responsabilidade está distribuída no sistema.

Classificação dos Design Patterns

Padrões de Criação Factory Method Define uma interface para criar um objeto, mas deixar que subclasses decidam que classe instanciar. Quando utilizar 1.Quando uma classe (o criador) não pode antecipar a classe dos objetos que deve criar; 2.Quando uma classe quer que suas subclasses especifiquem os objetos criados; 3.Quando classes delegam responsabilidade para uma entre várias subclasses de apoio e queremos localizar num ponto único a conhecimento de qual subclasse está sendo usada.

Padrões de Criação Abstract Factory Define uma interface para criar um objeto, mas deixar que subclasses decidam que classe instanciar. Quando utilizar 1.Quando uma classe (o criador) não pode antecipar a classe dos objetos que deve criar; 2.Quando uma classe quer que suas subclasses especifiquem os objetos criados; 3.Quando classes delegam responsabilidade para uma entre várias subclasses de apoio e queremos localizar num ponto único a conhecimento de qual subclasse está sendo usada.

Padrões de Criação Builder Separar a construção de objeto complexo da representação para criar representações diferentes com mesmo processo.   Quando Utilizar Use-o quando o algoritmo para criar um objeto complexo precisar ser independente das partes que compõem o objeto e da forma como o objeto é construído. 2. Use quando o processo de construção precisar suportar representações diferentes do objeto que está sendo construído  

Padrões de Criação Singleton Garantir que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela. Quando utilizar 1. Quando se deseja que haja uma única instância de uma determinada classe, permitindo que seja acessada por seus Clientes de forma global (ou seja, em qualquer ponto do código). Quando se deseja que o número de instâncias de uma determinada classe seja controlado e/ou limitado.

Padrões de Criação Prototype Especificar os tipos de objetos a serem criados usando uma instância como protótipo e criar novos objetos ao copiar este protótipo. Quando utilizar Criar um objeto novo, mas aproveitar o estado previamente existente em outro objeto.

Padrões de Criação Factory Method Define uma interface para criar um objeto, mas deixar que subclasses decidam que classe instanciar. Quando utilizar 1.Quando uma classe (o criador) não pode antecipar a classe dos objetos que deve criar; 2.Quando uma classe quer que suas subclasses especifiquem os objetos criados; 3.Quando classes delegam responsabilidade para uma entre várias subclasses de apoio e queremos localizar num ponto único a conhecimento de qual subclasse está sendo usada.

Padrões de Criação Factory Method Define uma interface para criar um objeto, mas deixar que subclasses decidam que classe instanciar. Quando utilizar 1.Quando uma classe (o criador) não pode antecipar a classe dos objetos que deve criar; 2.Quando uma classe quer que suas subclasses especifiquem os objetos criados; 3.Quando classes delegam responsabilidade para uma entre várias subclasses de apoio e queremos localizar num ponto único a conhecimento de qual subclasse está sendo usada.

Padrões de Criação Factory Method Define uma interface para criar um objeto, mas deixar que subclasses decidam que classe instanciar. Quando utilizar 1.Quando uma classe (o criador) não pode antecipar a classe dos objetos que deve criar; 2.Quando uma classe quer que suas subclasses especifiquem os objetos criados; 3.Quando classes delegam responsabilidade para uma entre várias subclasses de apoio e queremos localizar num ponto único a conhecimento de qual subclasse está sendo usada.

Padrões de Estrutura Adapter Converter a interface de uma classe em outra interface esperada pelos clientes. Adapter permite a comunicação entre classes que não poderiam trabalhar juntas devido à incompatibilidade de suas interfaces. Quando utilizar 1. Sempre que for necessário adaptar uma interface para um cliente da Classe Adapter 2. Quando houver uma interface que permita a implementação estática Objeto Adapter 3. Quando menor acoplamento for desejado 4. Quando o cliente não usa uma interface Java ou classe abstrata que possa ser estendida

Padrões de Estrutura Façade Oferecer uma interface única para um conjunto de interfaces de um subsistema. Façade define uma interface de nível mais elevado que torna o subsistema mais fácil de usar. Quando Utilizar Sempre que for desejável criar uma interface para um conjunto de objetos com o objetivo de facilitar o uso da aplicação.

Padrões de Estrutura Composite Compor objetos em estruturas de árvore para representar hierarquias todo-parte. Composite permite que clientes tratem objetos individuais e composições de objetos de maneira uniforme. Quando Utilizar Sempre que houver necessidade de tratar um conjunto como um indivíduo

Padrões de estrutura Bridge Desacoplar uma abstração de sua implementação para que os dois possam variar independentemente. Quando Utilizar Quando for necessário evitar uma ligação permanente entre a interface e implementação Quando alterações na implementação não puderem afetar clientes Quando tanto abstrações como implementações precisarem ser capazes de suportar extensão através de herança Quando implementações são compartilhadas entre objetos desconhecidos do cliente

Padrões de Estrutura Decorator Anexar responsabilidades adicionais a um objeto dinamicamente. Decorators oferecem uma alternativa flexível ao uso de herança para estender uma funcionalidade. Quando Utilizar Em Java, o uso mais comum de decoradores é nos objetos que representam fluxos de entrada e saída (I/O streams).

Padrões de Estrutura FlyWeight Usar compartilhamento para suportar grandes quantidades de objetos refinados eficientemente. Quando Utilizar Quando o tamanho do conjunto de objetos for significativamente menor que a quantidade de vezes em que eles são usados na aplicação. Quando objetos podem ser usados em diferentes contextos ao mesmo tempo (agindo sempre como um objeto independentemente).

Padrões de Estrutura Proxy Prover um substituto ou ponto através do qual um objeto possa controlar o acesso a outro. Quando Utilizar A aplicação mais comum é em objetos distribuídos.

Padrões de Comportamento Chain of Responsibility Evita acoplar o remetente de uma requisição ao seu destinatário ao dar a mais de um objeto a chance de servir a requisição. Compõe os objetos em cascata e passa a requisição através da cadeia até que um objeto seja capaz de atende-la. Quando Utilizar Quando for necessário que vários objetos possam servir a uma requisição ou repassá-la. Quando for necessária a divisão de responsabilidades de forma transparente

Padrões de Comportamento Observer Definir uma dependência um-para-muitos entre objetos para que quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente.   Quando Utilizar Quando for necessário garantir que objetos que dependem de outros fiquem em dia com mudanças de estado que ocorram.

Padrões de Comportamento Mediator Definir um objeto que encapsula como um conjunto de objetos interage. Mediator promove acoplamento fraco ao manter objetos que não se referem um ao outro explicitamente, permitindo variar sua interação independentemente. Quando Utilizar Quando for necessário viabilizar que um grupo de objetos se comunique entre si sem que haja acoplamento entre eles.

Padrões de Comportamento Template Method Definir o esqueleto de um algoritmo dentro de uma operação, deixando alguns passos a serem preenchidos pelas subclasses. Template Method permite que suas subclasses redefinam certos passos de um algoritmo sem mudar sua estrutura. Quando Utilizar Quando a estrutura fixa de um algoritmo puder ser definida pela superclasse deixando certas partes para serem preenchidos por implementações que podem variar

Padrões de Comportamento State Permitir a um objeto alterar o seu comportamento quanto o seu estado interno mudar. O objeto irá aparentar mudar de classe. Quando Utilizar Quando houver a necessidade de usar objetos para representar estados e polimorfismo para tornar a execução de tarefas dependentes de estado transparentes.

Padrões de Comportamento Strategy Definir uma família de algoritmos, encapsular cada um, e fazê-los intercambiáveis. Strategy permite que algoritmos mudem independentemente entre clientes que os utilizam. Quando Utilizar Quando classes relacionadas forem diferentes apenas no seu comportamento Strategy oferece um meio para configurar a classe com um entre vários comportamentos Quando você precisar de diferentes variações de um mesmo algoritmo Quando um algoritmo usa dados que o cliente não deve conhecer Quando uma classe define muitos comportamentos, e estes aparecem como múltiplas declarações condicionais em suas operações Strategy permite implementar as operações usando polimorfismo

Padrões de Comportamento Command Encapsular uma requisição como um objeto, permitindo que clientes parametrizem diferentes requisições, filas ou requisições de log, e suportar operações reversíveis. Quando Utilizar Parametrizar objetos por uma ação a realizar, como objetos MenuItem. Especificar, enfileirar e executar pedidos em tempos diferentes. Suportar ‘undo’ (desfazer). Estruturar um sistema em volta de operações de alto nível construídas sobre operações primitivas.

Padrões de Comportamento Iterator Prover uma maneira de acessar os elementos de um objeto agregado seqüencialmente sem expor sua representação interna.   Quando Utilizar Quando existe um conjunto de objetos (coleção) e é necessário implementar um método de percorrê-la.

Padrões de Comportamento Visitor Representar uma operação a ser realizada sobre os elementos de ma estrutura de objetos. Visitor permite definir uma nova operação sem mudar as classes dos elementos nos quais opera. Quando Utilizar Quando for necessário: Plugar nova funcionalidade em objetos sem precisar mexer na estrutura de herança; Agrupar e manter operações relacionadas em uma classe e aplicá-las, quando conveniente, a outras classes (evitar espalhamento e fragmentação de interesses); Implementar um Iterator para objetos não relacionados através de herança.

Padrões de Comportamento Memento Sem violar o encapsulamento, capturar e externalizar o estado interno de um objeto para que o objeto possa ter esse estado restaurado posteriormente.   Quando Utilizar Use Memento quando: Um snapshot do (parte do) estado de um objeto precisa ser armazenada para que ele possa ser restaurado ao seu estado original posteriormente; Uma interface direta para se obter esse estado iria expor detalhes de implementação e quebrar o encapsulamento do objeto.

J2EE Design Patterns No mundo do J2EE, existem geralmente três camadas: a camada de apresentação, uma aplicação Web construída ou com servlets Java ou com Java Server Pages (JSP), uma camada de lógica de negócio construída em Session Enterprise Java Beans (EJB) e/ou classes e uma camada de dados que acessa um servidor qualquer de persistência seja com um Entity EJB ou alguma solução de mapeamento O/R. Os patterns a seguir ajudam o desenvolvedor a melhorar a performance de seus sistemas em multi-camadas e torná-los mais fáceis de se manter ao reduzir a complexidade

J2EE Design Patterns Camada de Apresentação Camada de Lógica de Negócio Camada de Dados

Design Patterns da Camada de Apresentação Decorating Filter Facilita o pós e o pré processamento do request e response. Font Controller Disponibiliza um controller central para gerenciar o request View Helper Encapsula a lógica que está relacionada a formatação da apresentação nos componentes Helper Composite View Criar um objeto view a sub-componentes atômicos. Service To Worker Combina um componente de dispatcher com um FrontController and View Helper Patterns. Dispatcher View Uma variante do pattern Service to Work

Design Patterns da Camada de Lógica de Negócio - Business Delegate Desacopla a camada de apresentação da camada de negócio e disponibiliza uma interface de façade e proxy para a camada de negócio. Value Object Transporta dados entre as camadas. - Session Façade Esconde a complexidade do objeto de negócio centralizando o manuseio do processamento. Aggregate Entity represents a best practice for designing coarse-grained entity beans. - Value Object Assembler Monta composite value object a partir de múltiplos repositórios de dados. Value List Handler Gerencia a execução da query, o cache do resultado e do processamento Service Locator Encapsula a complexidade do processo de lookup e criação e alocação de factories de serviços de negócios.

Design Patterns da Camada de Lógica de Dados Data Access Object Cria uma abstração dos data sources e fornece um acesso transparente aos dados. Service Activator Facilita o processamento assíncrono para componentes EJB.