Padrões de projeto - Martin Fowler - P of EAA

2,122 views

Published on

Descrição de nove tipos de padrões de projeto de Martin Fowler.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,122
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
52
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Padrões de projeto - Martin Fowler - P of EAA

  1. 1. Curso: Tecnologia em Análise e Desenvolvimento de Sistemas Disciplina: Arquitetura de Software Prof. Msc. Petrônio Candido Lima e Silva Dupla: Aline Ferreira e Aricelio de Souza Turma: 5º Periodo
  2. 2. Catálogo de Design Patterns P of EAA – Martin Fowler Introdução ao catálogo Pof EA. . Lazy Load. . Service Layer. . Separated Interface. . Referências. . Value Object. . Query Object. . Repository. . Identity Map. . Unity of Work. . Active Record.
  3. 3. Introdução ao Catálogo P of EAA  O livro Patterns of Enterprise Application Architecture começou a ser desenvolvido depois de Davi Rice e Martin Fowler terem dado palestras sobre arquitetura J2EE e refletido sobre como os conceitos que haviam aprendido foram cruciais para o desenvolvimento de seus projetos.
  4. 4.  O livro tem o propósito de definir padrões de projeto para ajudar desenvolvedores, indepentente da plataforma que utilizam.  O livro é dividido em duas partes:  1ª parte: Tutorial sobre arquitetura de aplicações corporativas.  2ª parte: Referência para cerca de 40 tipos de padrões de projeto.  Para cada padrão é descrito como funciona e quando usá-lo, com exemplos em Java, C# ou ambos. Introdução
  5. 5. Lazy Load Lazy Load Finalidade O Lazy Load tem a finalidade de interromper o processo de carregamento de objetos que não serão usados. Ele coloca um marcador na estrutura dos objetos de modo que se os dados forem necessários à aplicação serão carregados apenas quando forem usados.
  6. 6. Lazy Load Como é implementado?  Inicialização Tardia (Lazy Inicialization).  Proxy Virtual (Virtual Proxy).  Armazenador de Valor (Value Holder).  Fantasma (Ghost).
  7. 7. Lazy Load Inicialização Tardia (Lazy Inicialization)  Abordagem mais simples.  Consiste em verificar se um campo é nulo antes de acessá-lo. Sendo nulo, ele calcula o valor do campo antes de retornar o mesmo.  Para que fucione, o campo a ser lido deve estar auto-encapsulado.
  8. 8. Lazy Load Exemplo
  9. 9. Lazy Load Proxy Virtual (Virtual Proxy)  É um objeto que parece com o objeto que deveria estar no campo, mas não contém nada.  Somente quando um dos seus métodos é chamado, ele carrega o objeto correto a partir do banco de dados.
  10. 10. Lazy Load Exemplo
  11. 11. Lazy Load Armazenador de Valor (Value Holder)  É um objeto que encapsula algum outro objeto.  Para obter o objeto subjacente, você solicita seu valor ao armazenador de valor.  Sua desvantagem é que a classe precisa saber que ele existe.
  12. 12. Lazy Load Exemplo
  13. 13. Lazy Load
  14. 14. Lazy Load Fantasma (Ghost)  É o objeto real em um estado parcial. Ao ser carregado do banco de dados, ele contém apenas seu ID.  Sempre que o acesso a um campo for solicitado, ele carrega seu estado completo.  Um fantasma é um objeto, onde cada campo é inicializado tardiamente.  O objeto é carregado de forma incompleta, porém com seu identificador (chave) e carrega seus dados no primeiro acesso a suas propriedades.
  15. 15. Lazy Load Exemplo
  16. 16. Separated Interface  Define uma interface para desacoplar uma camada de outra. As vezes é preciso contradizer a regra de dependencia entre camadas, por exemplo, uma camada acessar outra sem passar pelas intermediarias ou uma camada não depender de outra. Separated Interface
  17. 17.  Para por exemplo, a camada de apresentação acessar a camada de pesistência diretamente, a apresentação passaria a depender da interface da camada de pesistência.  Assim, mesmo que as classe da camada de pesistência mudem, se a interface não mudar, a apresentação não precisará mudar. Separated Interface
  18. 18. Separated Interface Exemplo
  19. 19. Separated Interface Exemplo
  20. 20. Separated Interface Exemplo
  21. 21. Value Object  Em diversas aplicações orientadas a objetos, muitos objetos possuem uma Identidade.  Uma importante classe de domínio como a classe Cliente terá vários atributos. O valor desse atributos é que diferenciam diferentes objetos de sua classe.  Portanto, um objeto com uma Identidade, PERSISTE, ou seja, ele existe durante toda aplicação. Value Object
  22. 22. Value Object Value Object  Mas existem situações em que alguns objetos NÃO precisam ter uma Identidade, pois esses objetos representam apenas características singulares de outros objetos.  Exemplos: Classe Dinheiro, Data, etc.  Esses objetos não precisam de uma identidade, pois representam somente valores, ou seja, eles não precisam persistir durante toda a aplicação.
  23. 23. Query Object  Segundo FOWLER (2006), Query Object é uma especialização do padrão Interpreter que constroi frases de consulta SQL com base em uma estrutura de objetos.  O padrão propõe que se utilize um objeto para conter todos os parametros necessários a construir a consulta SQL.  Um objeto que representa uma consulta ao banco de dados. Query Object
  24. 24. Query Object
  25. 25. Query Object
  26. 26. Identity Map  Segundo FOWLER (2006), esse padrão assegura que cada objeto seja carregado apenas uma vez, mantendo cada objeto carregado em um mapa. Assim, ele procura os objetos usando o mapa quando se referindo a eles.  Um identity map mantém um registro de todos os objetos que foram lidos do banco de dados em uma única transação de negócio. Identity Map
  27. 27. Identity Map  Sempre que quiser um objeto, você verifica o Mapa de identidade antes para ver se já o tem, semelhante a um cache.  Identity Map explicito: É acessado com métodos distintos para cada tipo de objeto que é preciso.  Identity Map genérico: Usa um único método para todos os tipos de objetos. Identity Map
  28. 28. Identity Map Exemplo
  29. 29. Active Record  O padrão Active Record encapsula a lógica para se criar uma linha na tabela correspondente a respectiva classe.  Onde,cada objeto sabe como ler e gravar seus dados no banco de dados, não existe uma camada específica para realizar essa tarefa. Active Record
  30. 30.  Este tipo de estrutura é indicada para sistemas menores onde a lógica de dominio não é tão complexa, como inserções,exclusões etc..  A estrutura dos dados dos objetos do Active Record devem ser exatamente iguais com a estrutura dos dados no Banco de Dados, o que dificulta a manutenção em razão da dependência entre os mesmos. Active Record
  31. 31. Exemplo Active Record
  32. 32. Exemplo Active Record
  33. 33. Active Record
  34. 34. Repository  O padrão Repository faz a mediação entre o domain model e as camadas de mapeamento de dados, agindo como uma coleção de objetos de domínio em memória FOWLER (2006).  Esta camada abstrai o acesso a camada de persistência, isolando a lógica de acesso aos dados de qualquer outra camada da aplicação. Repository
  35. 35.  Este padrão é indicado para o desenvolvimento de aplicações que possuem um grande número de classes e nescessitam de consultas mais pesadas, além de ajudar a minimizar as duplicações nas lógicas das consultas. Repository
  36. 36. Exemplo Repository
  37. 37. Unity of Work  Mantém uma lista de objetos afetados por uma transação de negócio e coordena a gravação das alterações e a desolução de problemas de concorrência FOWLER (2006). Unity of Work
  38. 38. Unity of Work  Uma Unit of work pode ser entendida como uma sessão ou objeto que mantém o registro de todas as atividades relacionadas ao banco de dados, realizadas durante uma transação de negócio, sendo também responsável pelo gerenciamento dos problemas de concorrência que podem ocorrer oriundos dessa transação. Unity of Work
  39. 39. Unity of Work  É indicada para situações onde são necessários:  Efetuar logs.  Tracing.  Gerenciar as transações.  Promover a testabilidade dos sistema, etc. Unity of Work
  40. 40. Exemplo Unity of Work
  41. 41. Unity of Work
  42. 42. Service Layer  Define os limites de uma aplicação com uma camada de serviços que estabelece um conjunto de operações disponíveis e coordena a resposta da aplicação em cada operação.  Uma Camada de Serviço define a fronteira de uma aplicação e seu conjunto de operações disponiveis, a partir da perspectiva das camadas de interface dos clientes. Service layer
  43. 43. Service Layer  Ela encapsula a lógica de negócio da aplicação, controlando as transações e coordenando as respostas na implementação de suas operações. Service layer
  44. 44. Service layer
  45. 45. Service layer
  46. 46. Referências ALMEIDA, Erico Renato Oliveira, Padrões de Projeto – Value Object. 2007. Disponivel em: <http://imasters.com.br/artigo/7293/linguagens/padroes-de- projeto-value-object/>. Acesso em: 16 Mar 2014. FOWLER, Martin. Padrões de Arquitetura de Aplicações Corporativas / Martin Fowler; tradução Acauan Fernandes. - Porto Alegre : Bookman, 2006. PIRES, Glauber Magalhães. Lazy Loading – Inicialização Preguiçosa. Disponivel em: <http://www.glauberpires.com.br/arquitetura/4-Lazy %20Loading.pdf>. Acesso em: 16 Mar 2014. RANIERI, Bárbara. Lazy Load – Quando usar?. 2013. Disponivel em: <http://www.princiweb.com.br/blog/programacao/aspnet/lazy- load-quando-usar.html>. Acesso em: 16 Mar 2014. Referências
  47. 47. SANTOS, Jadson José. Análise da Utilização de padrões no Desenvolvimento de Software em Camadas. 2008. Disponivel em: <http://jadsonjs.files.wordpress.com/2008/03/artigo-padroes- de-projeto-padroes-basicos.pdf>. Acesso em: 16 Mar 2014. TABORDA, Sérgio, Query Object. 2009. Disponivel em: <http://sergiotaborda.wordpress.com/desenvolvimento-de- software/java/patterns/query-object/>. Acesso em: 16 Mar 2014. Referências

×