Software robusto e flexível
Transferir como PPTX, PDF2 gostaram164 visualizações
O documento apresenta princípios de desenvolvimento de software orientado a objetos e ágil. Discute problemas comuns em software, como fragilidade e bugs. Apresenta os cinco princípios SOLID para criar sistemas fáceis de manter e extender. Também discute boas práticas como coesão, acoplamento, encapsulamento e composição sobre herança. Conclui enfatizando a importância do projeto de classes e do feedback do cliente.
Software robusto e flexível
- 1. SOFTWARE ROBUSTO E FLEXÍVEL SOLID + Dois Dedos de Orientação a Objetos
- 2. Robson Bittencourt 2 Desenvolvedor na CWI Software Gosto de repassar o que aprendo através de palestras e do meu blog Estou sempre estudando assuntos relacionados a desenvolvimento de software, principalmente: - Java - JavaScript - Qualidade de Código - Devops - Métodos Ágeis
- 3. Agenda 1. Problemas de Software 2. Software Frágil 3. Princípios SOLID 4. Boas Práticas da Orientação a Objetos 5. Conclusão 3
- 4. 4 Instigar a reflexão sobre como criamos sistemas Orientados a Objetos 0. OBJETIVO
- 6. “ Código ruim nos atrasa muito Uncle Bob 6
- 7. 60,000,000,000 Por ano de prejuízo com bugs de software somente nos EUA 7
- 9. “ Não apenas software em funcionamento, mas software de excelente qualidade Manifesto for Software Craftsmanship 9
- 11. Software Frágil 11 Qual é a maior constante no desenvolvimento de software?
- 12. Software Frágil 12 A mudança sempre é difícil de ser realizada
- 13. Necessidade de alteração em diversos lugares 13 Impacto 1 Impacto 2 Impacto 3 Impacto 4 ALTERAÇÃO
- 14. 2 -SOLID 14
- 15. SOLID 15 É um acrônimo formado por 5 princípios introduzidos por Robert C. Martin no início dos anos 2000. A intenção destes princípios é de ajudar a criar sistemas que sejam fáceis de manter e estender.
- 17. “ A class should have one, and only one, reason to change 17 Single Responsability Principle
- 18. Single Responsability 18 A mudança quando ocorre, deve ocorrer somente em um ponto
- 19. Single Responsability 19 Como definir o que é uma única responsabilidade?
- 22. “ Modules should be open to extension, but closed to modification 22 Open Closed Principle
- 23. Open Closed 23 Novas regras devem ser obtidas por código novo, sem alterar o existente
- 24. Open Closed 24 Programe para interfaces não para implementações
- 25. Open Closed 25 Evoluir o sistema criando novas implementações de abstrações existentes
- 29. “ Derived types must be completely substitutable for their base types 29 Liskov Substitution Principle
- 30. Liskov Substitution 30 A relação “É UM” quando falamos de herança, se refere a comportamento
- 35. “ Clients should not be forced to depend upon interfaces that they don’t use 35 Interface Segregation Principle
- 36. Interface Segregation 36 Muitas interfaces específicas são melhores do que uma interface única
- 39. “ High-level modules should not depend upon low-level modules. Both should depend upon abstractions 39 Dependency Inversion Principle
- 40. “ Abstractions should never depend upon details. Details should depend upon abstractions 40 Dependency Inversion Principle
- 41. Dependency Inversion 41 Sempre fazer sua classe depender de módulos mais estáveis
- 42. Dependency Inversion 42 Abstrações sempre devem depender de outras abstrações
- 45. 3 - Boas Práticas da Orientação a Objetos 45
- 46. Coesão 46 As propriedades e métodos da classe devem estar ligados ao mesmo objetivo
- 47. Como saber se uma classe é coesa? 1. A classe tem uma única responsabilidade? 2. Essa classe irá parar de crescer? 3. Você abre está classe para edição todos os dias? 47
- 48. Acoplamento 48 Nos acoplamos com outras classes quando dependemos delas
- 49. Acoplamento 1. Nem todo acoplamento é ruim 2. Devemos nos acoplar com classes estáveis, que são pouco alteradas 3. Interfaces tendem a ser estáveis 49
- 50. Encapsulamento 50 Você sabe acelerar um carro. Sabe que quando o faz o carro se movimenta. Mas você sabe todos os processos que ocorrem quando você aciona o acelerador?
- 56. Tell, Don't Ask 56 Devemos sempre dar ordens para chamar métodos. Não devemos perguntar antes de chamar.
- 58. Lei de Demeter Todos os métodos de uma classe devem se comunicar somente com: 1. Um membro da classe 2. Um argumento do método 58
- 61. Composition Over Inheritance 61 Não use herança somente para ganhar comportamentos
- 62. 4. CONCLUSÕES 62
- 63. Pensar no projeto de classes é fundamental 63
- 64. Implementação ruim não é um grande problema 64
- 65. Abstrair por abstrair pode acabar criando over-engineering 65
- 66. Como identificar os pontos para abstração? Obtenha feedback do cliente o quanto antes 66 Procure ajuda de outros programadores Leve o primeiro tiro
- 67. 67 Reforçando SOLID Os cinco princípios Encapsulamento Esconda o funcionamento Coesão Todos pelo mesmo objetivo
- 68. 68 Reforçando Herança Use com cuidado, favoreça a composição Acoplamento Controle suas dependências Modelos Anêmicos Não separe os dados do comportamento
- 69. Fontes 69 ▪ Bob Martin SOLID Principles of Object Oriented and Agile Design ▪ Manifesto for Software Craftsmanship ▪ https://www.casadocodigo.com.br/products/livro-oo-solid ▪ https://weblogs.asp.net/andrenobre/princ-237-pios-de-oop-a-lei-de-demeter-lod ▪ http://www.davesquared.net/2009/01/introduction-to-solid-principles-of-oo.html ▪ http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod ▪ http://blog.scottbellware.com/2009/01/good-design-is-easily-learned.html ▪ Código fonte dos exemplos: https://github.com/robsonbittencourt/palestra-solid-oo
- 70. Obrigado 70 Blog: rbittencourt.com Github: robsonbittencourt Skype: rluizv E-mail: robson.luizv@gmail.com
Notas do Editor
- #5: Vou mostrar vários conceitos e bastante código A ideia não é ensinar todos Cada um daria uma hora de palestra sozinho provavelmente
- #7: Quem nunca perdeu muito tempo em tarefas que deveriam ser fáceis? Desenvolve a solução e aparecem bugs durante os testes e precisa desenvolver novamente.
- #9: Fazer a comparação com um cirurgião
- #10: Pois a qualidade do código vai garantir o funcionamento futuro do sistema
- #11: Isso nos leva a termos sistemas frágeis Fazer a comparação com o Jenga
- #12: A mudança As vezes achamos que aquele código não vai mudar, mas cedo ou tarde ele muda
- #13: As vezes para fazer uma mudança temos que alterar em vários lugares Podemos esquecer de alterar um lugar
- #15: Para tentar melhorar isso vamos começar a falar de SOLID
- #16: 5 princípios mapeados pelo Uncle Bob em 2000 Formam um acrônimo Ele não inventou os princípios, eles já existiam a muito tempo Objetivo é criar sistemas fáceis de manter e estender
- #18: Ou seja ela deve ter uma única responsabilidade
- #19: A mudança deve se propagar para o sistema
- #20: A classe não para de crescer Verificar a existência de muitos ifs Ao perguntar o que a classe/método faz respondemos com um “E”
- #22: Mais tarde será mostrado como utilizar estas classes
- #24: Fazer comparação com Lego Contar história da tarefa que parecia difícil
- #25: Devemos sempre pensar nas abstrações antes das implementação
- #29: Não preciso mais abrir o GerenciadorFaturas quando uma nova ação aparecer
- #33: Se o banco tiver somente contas comuns não vai dar erro Mas se tiver uma conta de estudante vai
- #39: Se quisermos podemos ainda implementar duas interfaces
- #50: Citar o acoplamento com List
- #51: pensar com muito cuidado em quais métodos são públicos em uma classe não criar seters pra tudo
- #53: Antes o enum deixava vazar a regra de que existia um cálculo para o salário
- #61: Falar sobre o acoplamento escondido com as duas classes
- #64: Temos que gastar mais tempo pensando e desenhando as soluções Uma vez projetado, codificar não deve ser difícil
- #65: A mudança do HashMap de LinkedList para Árvore Binária
- #66: Difícil de entender
- #67: Não crie um strategy se você só tem um tipo de imposto