Padrões De Projeto e Anti Patterns

7,446 views

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,446
On SlideShare
0
From Embeds
0
Number of Embeds
84
Actions
Shares
0
Downloads
340
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Padrões De Projeto e Anti Patterns

  1. 1. Padrões de Projeto e Anti-Patterns Débora Kelly Gouvêia Herval Freire de A. Júnior
  2. 2. Introdução <ul><li>Padrões – situações comuns catalogadas e esquematizadas </li></ul><ul><li>Conceito comum na engenharia civil e na arquitetura </li></ul><ul><li>Formam um jargão que permite a descrição mais completa de um sistema arquitetônico </li></ul><ul><li>Garantem qualidade e reusabilidade </li></ul>
  3. 3. Padrões (Patterns) <ul><li>Solução de um problema conhecido </li></ul><ul><li>Otimização de uma estrutura ou processo </li></ul><ul><li>Esquema arquitetural que permite reuso e expansibilidade </li></ul><ul><li>Solução mais indicada para um cenário </li></ul>
  4. 4. Um pouco de história... <ul><li>Inspiração: Christopher Alexander (Padrões de Arquitetura) </li></ul><ul><li>Anos 80 – Ward Cunningham e Kent Beck (Padrões para SmallTalk), Jim Coplien (Idiomas para C++) </li></ul><ul><li>1994 – Lançamento do livro da Gang-of-Four (Gamma, Helm, Johnson e Vlissides) </li></ul>
  5. 5. Tipos de Padrões <ul><li>Padrões Arquiteturais </li></ul><ul><li>Padrões de Projeto </li></ul><ul><ul><li>De Criação/Estruturais/Comportamentais </li></ul></ul><ul><li>Idiomas </li></ul><ul><ul><li>Padrões para uma linguagem específica </li></ul></ul>
  6. 6. Padrões Arquiteturais <ul><li>Padrões de alto nível (arquitetura de sistemas) </li></ul><ul><ul><li>MVC </li></ul></ul><ul><ul><li>Layered Application </li></ul></ul><ul><ul><li>Container Model </li></ul></ul>
  7. 7. Padrões de Projeto <ul><li>Padrões a nível de design </li></ul><ul><li>Soluções para situações-problema </li></ul><ul><li>Garantir qualidade à aplicação </li></ul><ul><ul><li>Flexibilidade </li></ul></ul><ul><ul><li>Reuso </li></ul></ul><ul><ul><li>Baixo acoplamento </li></ul></ul><ul><ul><li>Extensibilidade </li></ul></ul>
  8. 8. Padrões de Projeto <ul><li>Padrões de Criação </li></ul><ul><ul><li>Como instanciar objetos? </li></ul></ul><ul><ul><li>Modularizar e flexibilizar a criação, composição e representação de objetos. </li></ul></ul>
  9. 9. Estudo de caso: Kiloton Racing <ul><li>Caso: A Kiloton Associates precisa desenvolver um jogo de corrida de carros </li></ul><ul><ul><li>Vários tipos de carros de corrida: motores, chassis e pneus diferenciados </li></ul></ul><ul><ul><li>Carros de duas marcas - Renault e Peugeot, com estruturas diferentes </li></ul></ul>
  10. 10. Kiloton Racing <ul><li>Problema: instanciação dos carros requer muitos detalhes </li></ul><ul><ul><li>Solução ruim: instanciar e configurar manualmente </li></ul></ul><ul><ul><ul><li>CarroRenault carro = new CarroRenault(); </li></ul></ul></ul><ul><ul><ul><li>carro.setChassis(new ChassisRenault()); </li></ul></ul></ul><ul><ul><ul><li>carro.setMotor(new MotorFrances()); </li></ul></ul></ul><ul><ul><ul><li>carro.setPneus(new PneusFirestone()); </li></ul></ul></ul><ul><ul><ul><li>CarroPeugeot carro = new CarroPeugeot(); </li></ul></ul></ul><ul><ul><ul><li>carro.setChassis(new ChassisPeugeot()); </li></ul></ul></ul><ul><ul><ul><li>carro.setMotor(new MotorAlemao()); </li></ul></ul></ul><ul><ul><ul><li>carro.setPneus(new PneusBridgestone()); </li></ul></ul></ul>E se tivermos que produzir carros Ford ou Chevrolet?
  11. 11. Kiloton Racing <ul><li>Solução padronizada: </li></ul><ul><ul><li>Abstract Factory </li></ul></ul><ul><ul><li>“ Prover uma interface que permita a criação de objetos relacionados ou dependentes sem especificar sua classe concreta ” </li></ul></ul>
  12. 12. Kiloton Racing <ul><li>Padrão Abstract Factory </li></ul>
  13. 13. Kiloton Racing <ul><li>Fábricas de Carros </li></ul>Método fabricaCarro() trata de “fabricar” os detalhes do carro
  14. 14. <ul><li>Utilizando as Fábricas de Carros </li></ul><ul><li>Carros de outras montadoras? </li></ul><ul><ul><li>Basta criar nova subclasse de Carro e de FabricaDeCarro </li></ul></ul>Kiloton Racing CarroRenault carro1 = FabricaRenault.fabricaCarro(); CarroPeugeot carro2 = FabricaPeugeot.fabricaCarro();
  15. 15. Padrões de Projeto <ul><li>Padrões Estruturais </li></ul><ul><ul><li>Como compor objetos? </li></ul></ul><ul><ul><li>Como definir estruturas funcionais? </li></ul></ul><ul><ul><li>Lidar com adaptação e interfaceamento entre componentes de uma estrutura maior </li></ul></ul>
  16. 16. Estudo de caso: C++ Sockets <ul><li>Caso: Leônidas precisa criar classes de manipulação de sockets em C++ que possam ser utilizadas em Linux, Unix, Windows, MacOS, OS/2, PalmOS, Calculadoras... </li></ul><ul><ul><li>API igual para qualquer plataforma </li></ul></ul><ul><ul><li>Dependência de recursos de SO diferenciados </li></ul></ul>
  17. 17. C++ Sockets <ul><li>Solução ruim: emaranhado de #ifdefs </li></ul><ul><li>void Socket::accept() { </li></ul><ul><li>#ifdef SO_WIN32 </li></ul><ul><li>// Solução para win32 </li></ul><ul><li>#endif </li></ul><ul><li> #ifdef SO_UNIX </li></ul><ul><li>// Solução para unix </li></ul><ul><li>#endif </li></ul><ul><li>... </li></ul><ul><li>} </li></ul>
  18. 18. C++ Sockets <ul><li>Solução padronizada: </li></ul><ul><ul><li>Bridge </li></ul></ul><ul><ul><li>“ Desacoplar abstrações de suas implementações para que as duas partes possam variar independentemente ” </li></ul></ul>
  19. 19. C++ Sockets <ul><li>Padrão Bridge </li></ul>
  20. 20. C++ Sockets <ul><li>SocketImpl </li></ul>
  21. 21. C++ Sockets <ul><li>Utilizando a SocketImpl </li></ul><ul><li>Em Windows: </li></ul><ul><li>Socket sock = new Socket(new SocketWin32()); </li></ul><ul><li>Em Linux: </li></ul><ul><li>Socket sock2 = new Socket(new SocketLinux()); </li></ul><ul><li>Novos S.O.s: implemente uma SocketImpl específica </li></ul>
  22. 22. Padrões de Projeto <ul><li>Padrões comportamentais </li></ul><ul><ul><li>Como lidar com comportamento dos objetos? </li></ul></ul><ul><ul><li>Permitir interações dinâmicas entre grupos de classes e objetos, de forma a facilitar o entendimento fluxos de dados complexos. </li></ul></ul>
  23. 23. Estudo de caso: JChat <ul><li>Sabrina está implementando um chat e precisa de uma interface que fique “ouvindo” mensagens chegando por um socket e exiba-as em uma caixa de texto </li></ul>
  24. 24. JChat <ul><li>Solução ruim 1: acoplar o socket à interface gráfica </li></ul><ul><ul><li>Uma só classe que cuida da interface e da conexão (socket) com o servidor </li></ul></ul>
  25. 25. JChat <ul><li>Solução ruim 2: criar um processo na classe da interface que fique “ouvindo” por mensagens </li></ul><ul><ul><li>Processo em loop infinito dentro da classe de interface ouvindo por mensagens </li></ul></ul><ul><ul><li>E se precisarmos tratar as mensagens? </li></ul></ul><ul><ul><li>Como fazer manutenção facilmente em um “objeto-faz-tudo”? </li></ul></ul>
  26. 26. JChat <ul><li>Solução padronizada: </li></ul><ul><ul><li>Observer </li></ul></ul><ul><ul><li>“ Definir um relacionamento um-para-muitos entre objetos, de forma que todos os objetos dependentes são notificados e atualizados automaticamente quando o estado do objeto observado mudar ” </li></ul></ul>
  27. 27. JChat <ul><li>Padrão Observer </li></ul>
  28. 28. JChat <ul><li>JChatEvents </li></ul>
  29. 29. JChat <ul><li>Utilizando os JChatEvents </li></ul><ul><ul><li>InterfaceGrafica: implementar a interface Ouvinte e registrar-se como ouvinte da conexão </li></ul></ul>
  30. 30. JChat <ul><ul><li>public class InterfaceGrafica implements Ouvinte { </li></ul></ul><ul><ul><li> public InterfaceGrafica(ConexaoJChat con) { </li></ul></ul><ul><ul><ul><li> con.adiciona(this); </li></ul></ul></ul><ul><ul><ul><li>} </li></ul></ul></ul><ul><ul><ul><li>public void onMensagem(String msg) { </li></ul></ul></ul><ul><ul><ul><li>textarea.append(“Mensagem: ” + msg); </li></ul></ul></ul><ul><ul><ul><li>} </li></ul></ul></ul><ul><ul><ul><li>} </li></ul></ul></ul>
  31. 31. JChat <ul><li>Utilizando os JChatEvents </li></ul><ul><ul><li>ConexaoJChat: a cada mensagem recebida, chamar o método notificaOuvintes() </li></ul></ul>
  32. 32. Idiomas <ul><li>Padrões específicos para uma Linguagem de Programação </li></ul><ul><ul><li>Cursor/Iterator </li></ul></ul><ul><ul><li>Template Handling (C++) </li></ul></ul>
  33. 33. Anti-Patterns <ul><li>O que são? </li></ul><ul><li>Tipos de Anti-Patterns </li></ul><ul><li>Exemplos! </li></ul>
  34. 34. Anti-Patterns <ul><li>Soluções péssimas adotadas em projetos </li></ul><ul><li>Documentação de más práticas </li></ul><ul><li>Indicação de como solucionar problemas comuns </li></ul>
  35. 35. Tipos de Anti-Patterns <ul><li>Arquitetura </li></ul><ul><li>Desenvolvimento </li></ul><ul><li>Gerência </li></ul>
  36. 36. Anti-Patterns <ul><li>Anti-Patterns de Arquitetura </li></ul><ul><ul><li>Problemas comuns nas fases de concepção, projeto e desenho de um sistema </li></ul></ul>
  37. 37. Anti-Patterns de Arquitetura <ul><li>Intellectual Violence </li></ul><ul><ul><li>Falas Típicas: </li></ul></ul><ul><ul><li>“ Utilizei um schema validator para poder validar se era possivel o marshalling daquele stub” </li></ul></ul><ul><ul><li>“ Esta classe trabalha com o conceito de autômato-finito de três estados para fazer a busca em back-tracking em uma árvore binária” </li></ul></ul><ul><ul><li>Resumo: Membros da equipe utilizam-se de teorias e termos desconhecidos pelos demais </li></ul></ul><ul><ul><li>Solução: estimular a difusão de conhecimentos dentro da equipe </li></ul></ul>
  38. 38. Anti-Patterns de Arquitetura <ul><li>Reinventing the Wheel </li></ul><ul><ul><li>Falas Típicas: </li></ul></ul><ul><ul><li>“ Escrevemos uma classe para manipular XML melhor do que as classes oficiais do C++!” </li></ul></ul><ul><ul><li>“ A ferramenta de UML era muito ruim, por isso decidimos implementar uma outra...” </li></ul></ul><ul><ul><li>Resumo: Decisão de reimplementar tecnologias já existentes ou fazer “ao jeito da equipe” atrasam e confundem o projeto </li></ul></ul><ul><ul><li>Solução: Pesquisa em busca da melhor solução e utilização de padrões </li></ul></ul>
  39. 39. Anti-Patterns <ul><li>Anti-Patterns de Desenvolvimento </li></ul><ul><ul><li>Problemas comuns na codificação e desenvolvimento de aplicações </li></ul></ul>
  40. 40. Anti-Patterns de Desenvolvimento <ul><li>Golden Hammer </li></ul><ul><ul><li>Falas Típicas: </li></ul></ul><ul><ul><li>“ Utilizamos XML para representar os objetos. E também para servir como banco de dados, troca de mensagens, armazenar imagens codificadas, substituir as páginas html, e também para...” </li></ul></ul><ul><ul><li>Resumo: U m conceito ou tecnologia familiar é aplicado de forma errada, para resolver todo e qualquer problema. </li></ul></ul><ul><ul><li>Solução: Estudo de novas idéias e soluções, treinamento e exposição a novos paradigmas permite pensar em soluções mais adequadas </li></ul></ul>
  41. 41. Anti-Patterns de Desenvolvimento <ul><li>The Blob </li></ul><ul><ul><li>Falas típicas: </li></ul></ul><ul><ul><li>“ Para manipular qualquer tipo de documento, utilizamos a classe UtilidadesDocumento. Os 145 métodos dela permitem ler e salvar documentos .doc, .xls, .txt, .rtf, .html, .xml... Uma beleza!” </li></ul></ul><ul><ul><li>Resumo: Classes são implementadas ao estilo procedural, algumas com centenas de métodos e outras apenas como depósitos de dados . </li></ul></ul><ul><ul><li>Solução: Redistribuição de responsabilidades e reengenharia </li></ul></ul>
  42. 42. Anti-Patterns <ul><li>Anti-Patterns de Gerência </li></ul><ul><ul><li>Problemas que atingem a gerência de pessoal e de projetos </li></ul></ul>
  43. 43. Anti-Patterns de Gerência <ul><li>Smoke and Mirrors </li></ul><ul><ul><li>Falas Típicas: </li></ul></ul><ul><ul><li>“ Como assim ‘protótipo de interface’?” (cliente confuso) </li></ul></ul><ul><ul><li>“ Mas as telas já estão prontas, por que o programa não está funcionando ainda??” (cliente enfurecido) </li></ul></ul><ul><ul><li>Resumo: Usuário final assume que uma demonstração já pode ser utilizada como produto final </li></ul></ul><ul><ul><li>Solução: É importante situar o usuário quanto ao processo de desenvolvimento e suas fases </li></ul></ul>
  44. 44. Anti-Patterns de Gerência <ul><li>The Feud </li></ul><ul><ul><li>Falas Típicas: </li></ul></ul><ul><ul><li>“ João, seu incompetente!” </li></ul></ul><ul><ul><li>“ A equipe de Recife é muito melhor do que esta aqui” </li></ul></ul><ul><ul><li>Resumo: Brigas entre a gerência e membros da equipe causam mal-estar e diminuem a produtividade geral </li></ul></ul><ul><ul><li>Solução: conflitos devem ser solucionados o mais rápido possível, se possível com confraternizações </li></ul></ul>
  45. 45. Considerações Finais <ul><li>O conhecimento de padrões e contra-padrões permite decidir o que deve ser feito e o que deve ser evitado </li></ul><ul><li>Sistemas baseados em padrões têm mais qualidade </li></ul><ul><li>Equipes que evitam contra-padrões têm menos surpresas desagradáveis </li></ul>
  46. 46. Referências na Internet <ul><li>Pattern Digest – http://patterndigest.com </li></ul><ul><li>Anti-Patterns Depot – http://www.antipatterns.com </li></ul>

×