Projeto e Implementação de Software Utilizando Padrões
Transferir como PPTX, PDF2 gostaram3,342 visualizações
O documento discute padrões de projeto de software, incluindo de onde vêm os padrões, conceitos de padrões, por que estudá-los e alguns padrões específicos como GRASP. Aborda princípios como atribuir responsabilidades ao especialista na informação e manter acoplamento fraco e alta coesão. Também fornece dicas sobre como tomar decisões de projeto usando padrões.
Projeto e Implementação de Software Utilizando Padrões
- 1. Projeto e implementação de software utilizando padrões de projetoAntonio Passos
- 2. AgendaDe onde vêm os padrões? Conceito de padrãoPor que estudar padrões?Alguns padrões conhecidos Padrões GRASPComo tomar decisões de projetoPra saber mais
- 3. De onde vêm os padrões?Algo em comum aqui?Escadaria Selarón - RJBiblioteca Nacional - RJ
- 4. De onde vêm os padrões?Pirâmide de Kukulcán - México
- 5. De onde vêm os padrões?Pirâmide de Kukulcán - México
- 6. De onde vêm os padrões?A beleza está realmente nos olhos de quem vê?Ou existe base objetiva para tal julgamento?
- 7. De onde vêm os padrões?
- 8. É possível projetar sistemas de forma metódica, racional, explicável?
- 9. Conceitos de padrõesPar nomeado problema/solução que pode ser aplicado em novos contextos, com conselhos sobre sua aplicação em novas situações e uma discussão sobre as consequências de seu usoPadrões constituem um repertório de princípios gerais e de soluções idiomáticas elaborado por desenvolvedores experientes que os guiam na construção de softwareÉ uma técnica, uma diretriz
- 10. Por que estudar padrões?Melhorar a comunicação da equipe e o aprendizado individualAumentar a capacidade de modificação melhorada do códigoReutilizar soluçõesDecidir se disponho do projeto certo, não apenas de um projeto que funcione
- 12. Arquitetura de aplicações corporativas
- 13. GRASP
- 14. Padrões GRASPPadrões de Princípios Gerais para Atribuição de Responsabilidade (General Responsibility Assignment Software Patterns)
- 15. Padrões GRASPEspecialista na informaçãoProblemaQual é o princípio básico de atribuição de responsabilidades a objetos?SoluçãoAtribuir a responsabilidade ao especialista na informação: a classe que tem a informação necessária para satisfazer a responsabilidade.BenefíciosO encapsulamento de informações é mantido.São estimuladas definições de classes « leves », de maior coesão, mais fáceis de compreender e manter.
- 16. Padrões GRASPCriadorProblemaQuem deve ser responsável pela criação de uma nova instância de uma classe?SoluçãoAtribua à classe B a responsabilidade de criar uma instância da classe A se uma das seguintes condições for verdadeira:B agrega objetos de A;B contém objetos de A;B registra instâncias de objetos de A;B usa de maneira muito próxima objetos de A;B tem os dados de iniciação que serão passados para A quando ele for criado.BenefíciosFavorece o acoplamento fraco
- 17. Padrões GRASPAcoplamento fracoProblemaComo favorecer a dependência baixa, o pequeno impacto à mudança e aumentar a reutilização?SoluçãoAtribuir uma responsabilidade de maneira que o acoplamento permaneça fraco.BenefíciosNão é afetado por mudanças em outros componentes;É simples de entender isoladamente;É conveniente para reutilização
- 18. Padrões GRASPAcoplamento fracoOpção 01Opção 02
- 19. Padrões GRASPCoesão altaProblemaComo manter a complexidade sob controle?SoluçãoAtribuir uma responsabilidade de forma que a coesão permaneça alta.BenefíciosMais clareza e facilidade de compreensão no projeto;Simplificação da manutenção e do acréscimo de melhorias;Favorecimento do acoplamento fraco;Aumento do potencial de reutilização
- 20. Padrões GRASPCoesão altaComo manter a complexidade sob controle?Acoplamento baixo
- 21. Como favorecer a dependência baixa, o pequeno impacto à mudança e aumentar a reutilização?Padrões GRASPControladorProblemaQuem deve ser responsável por tratar um evento de sistema?SoluçãoAtribuir a responsabilidade de receber ou tratar uma mensagem de um evento do sistema a uma classe que represente uma das seguintes escolhas:Represente todo o sistema, dispositivo ou subsistema;Represente um cenário de um caso de uso dentro do qual ocorra o evento do sistemaBenefíciosAumento das possibilidades de reutilização e de interfaces plugáveis;Conhecer o estado do caso de uso
- 22. Como tomar decisões de projeto?Qual dessas implementações é a melhor?Sob quais circunstâncias esta alternativa seria melhor que a outra?
- 23. Qual dessas circunstâncias é a que mais se assemelha ao meu domínio do problema?Pra saber maisJAVA DESIGN PATTERNShttp://www.allapplabs.com/java_design_patterns/java_design_patterns.htmJava Design Patterns At a Glancehttp://www.javacamp.org/designPattern/Java Design Patterns Reference and Exampleshttp://www.fluffycat.com/Java-Design-Patterns/