A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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.

Apresentações semelhantes


Apresentação em tema: "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."— 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) 1.Esses patterns podem ser usados repetidas vezes, facilitando a incorpora ç ão da experiência de desenvolvimentos anteriores em novos projetos ; 2.Patterns tamb é m fornecem uma linguagem comum para a discussão de arquitetura de software em um n í vel mais elevado; 3.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 1.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). 2.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 oQuando for necessário evitar uma ligação permanente entre a interface e implementação oQuando alterações na implementação não puderem afetar clientes oQuando tanto abstrações como implementações precisarem ser capazes de suportar extensão através de herança oQuando 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 o Quando o tamanho do conjunto de objetos for significativamente menor que a quantidade de vezes em que eles são usados na aplica ç ão. 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 o Quando for necess á rio que v á rios objetos possam servir a uma requisi ç ão ou repass á -la. o 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 o Quando classes relacionadas forem diferentes apenas no seu comportamento o Strategy oferece um meio para configurar a classe com um entre v á rios comportamentos o Quando você precisar de diferentes varia ç ões de um mesmo algoritmo o Quando um algoritmo usa dados que o cliente não deve conhecer o Quando uma classe define muitos comportamentos, e estes aparecem como m ú ltiplas declara ç ões condicionais em suas opera ç ões o 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 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: o Um snapshot do (parte do) estado de um objeto precisa ser armazenada para que ele possa ser restaurado ao seu estado original posteriormente; o Uma interface direta para se obter esse estado iria expor detalhes de implementação e quebrar o encapsulamento do objeto. Padrões de Comportamento

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.


Carregar ppt "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."

Apresentações semelhantes


Anúncios Google