Transferir como PDF, PPTX
Mais conteúdo relacionado
Boas práticas no desenvolvimento de software
- 1.
- 2. Olá! Eu sou CarlosAlberto Arquiteto de software CAPES @euprogramador euprogramador@gmail.com
- 3. Desenvolvimento de software édifícil Como organizar o código?
- 4. “Se você estátendo um problema no desenvolvimento, você não está sozinho. Outro já passou pelo mesmo problema e já deve ter solução para o problema.
- 5.
- 6. S ingle principle Open closed L iskov Substitution I nterface segregation D ependency Inversion S.O.L.I.D.
- 7. Single responsability × Suaclasse deve ser responsável por apenas um comportamento × Deve fazer apenas 1 coisa × Deve fazer bem
- 8. Single responsability O quehá de errado nessa classe?
- 9. Single responsability Após aplicarSingle responsability?
- 10. × Classes devempoder extender seu comportamento, facilmente, seja por herança, interface ou composição. × Temos de ter boas abstrações. Open Closed
- 11.
- 12. Liskov Substitution × Herançaé bom. × Cuidado com a herança. × Projeto por contrato. × Estabelece regras para uso × Pré condições - não podem ser mais fortes que a super-classe. × Pós condições - não podem ser enfraquecidas Eventualmente desenvolvedor escolhe herança
- 13. Liskov Substitution Exemplo debom uso:
- 14. Liskov Substitution Exemplo deproblemas com o uso de herança: × Properties não deveria ser uma Hashtable, pois tem o put(object, object) se for usado pode causar problemas. × Vector é sincronizado, todas as stacks deveriam ser sincronizadas?
- 15. Liskov Substitution Exemplo deproblemas com o uso de herança: × CEP você busca do correios × CEP deveria pode salvar ou remover?
- 16. Liskov Substitution Alternativas parao uso de herança? Composição:
- 17. Interface Segregation × Módulosenxutos × Pouco comportamento (método) × Desenvolvimento orientado a interface
- 18.
- 19. Dependency Inversion × Dependade abstrações não implementações × Facilita mudar no futuro
- 20.
- 21. Padrões de Projeto- Principios de design Princípios Dependency Injection Inversion of Control
- 22. Inversion of control ×Princípio de Hollywood, “Não ligue para nós, nós ligamos para você.” × Controle das chamadas é invertido não é determinado pelo programador. × Controle é delegado a uma infraestrutura, container.
- 23. Inversion of control- Exemplos Spring:
- 24. Inversion of control- Exemplos Weld/CDI:
- 25.
- 26. Dependency Injection Tipos Constructor Injection PropertyInjection Method Injection Service Locator
- 27.
- 28.
- 29.
- 30.
- 31. Dependency Injection Melhor Padrão ×Injeção no construtor, good citizen (bom cidadão) × Tudo que a classe precisa é passado no construtor. × Garantia de inicialização somente quando atendido as dependências. Nem tudo são flores × Não são todos os frameworks de IOC/DI que implementam
- 32. Padrões de Projeto ×Solução para um problema frequente × Reusavéis Padrões de projeto dizem respeito a como organizar o código.
- 33. “GOF - Gangof Four” Padrões a serem conhecidos
- 34. Padrões de Projeto- Categorias Criacionais Factory Method Abstract Method Builder Prototype Singleton Estruturais Composite Adapter Bridge Decorator Facade Proxy Flyweight Comportamentais Strategy Template Method Observer Mediator Command Chain of Responsability State Visitor ...
- 35. Padrões de Projeto- Categorias Criacionais Factory Method Abstract Method Builder Prototype Singleton Estruturais Composite Adapter Bridge Decorator Facade Proxy Flyweight Comportamentais Strategy Template Method Observer Mediator Command Chain of Responsability State Visitor ...
- 36. Factory / AbstractFactory Padrão criacional
- 37.
- 38.
- 39. “Dependency Injection simplifica ou acabacom todos eles”
- 40. Dependency Injection Padrão criacional ×Desacopla a solicitação de uma dependência da sua instanciação × Simplifica código × Melhora isolamento × Testável
- 41. Dependency Injection Factory énecessária? Builder é necessário?
- 42. Dependency Injection -Scopes Define o ciclo de vida do objeto
- 43. Padrões de Projeto- Categorias Criacionais Factory Method Abstract Method Builder Prototype Singleton Estruturais Composite Adapter Bridge Decorator Facade Proxy Flyweight Comportamentais Strategy Template Method Observer Mediator Command Chain of Responsability State Visitor ...
- 44. Composite Representa um objetocomo uma composição de objetos similares Trata um conjunto de objetos como um unico objeto
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53. Flyweight Permite economizar memória Compartilhamentode objetos Exemplo: String do java possui um pool interno
- 54. Padrões de Projeto- Categorias Criacionais Factory Method Abstract Method Builder Prototype Singleton Estruturais Composite Adapter Bridge Decorator Facade Proxy Flyweight Comportamentais Strategy Template Method Observer Mediator Command Chain of Responsability State Visitor ...
- 55. Strategy Permite a trocade algoritmos Muda comportamento conforme contexto
- 56.
- 57. Adiciona uma indireçãoentre componentes Favorece um baixo acoplamento Cuidado. Observer
- 58.
- 59.
- 60.
- 61.
- 62. State Permite mudar de comportamento Simplificaifs para tratar estado
- 63.