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.

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

11. Gangue dos Quatro

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/

24. ObrigadoAntonio PassosE-mail: antoniopassos@gmail.com