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

Apresentação em tema: "Padrões de Projeto Aplicações empresariais são complexas"— Transcrição da apresentação:

1 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.

2 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.

3 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;

4 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.

5 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.

6 Classificação dos Design Patterns

7 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.

8 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.

9 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  

10 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.

11 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.

12 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.

13 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.

14 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.

15 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

16 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.

17 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

18 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

19 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).

20 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).

21 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.

22 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

23 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.

24 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.

25 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

26 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.

27 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

28 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.

29 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.

30 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.

31 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.

32

33 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

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

35 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

36 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.

37 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.