qualidade de código: boas práticas, princípios e padrões

5,601 views
5,489 views

Published on

Published in: Technology, Health & Medicine
3 Comments
4 Likes
Statistics
Notes
No Downloads
Views
Total views
5,601
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
72
Comments
3
Likes
4
Embeds 0
No embeds

No notes for slide

qualidade de código: boas práticas, princípios e padrões

  1. 1. Qualidade de Código: boas práticas, princípios e padrões. @edgarddavidson http://edgarddavidson.com
  2. 2. Curso de Pós Graduação em Engenharia de Software Centrada em Métodos Ágeis http://engenhariadesoftwareagil.com
  3. 3. Curso de Pós Graduação em Teste e Qualidade de Softwarehttp://testeequalidadedesoftware.com
  4. 4. Referências
  5. 5. <trollagem>
  6. 6. Um típico implementador de POG convícto
  7. 7. 1°encontro dosimplementadores de POG convíctos
  8. 8. Projeto entregue pelosimplementadores de POG convíctos
  9. 9. Um dia típico de trabalho de um implementador de POG convícto
  10. 10. Implementadores de POG convíctos também trabalham em equipe
  11. 11. Um implementador de POG convícto não tem medo do perigo
  12. 12. Um implementador de POG convícto assume que boas práticas, princípios e padrões é tudo um VIAGEM
  13. 13. Por algummotivo oserros se repetem
  14. 14. </trollagem>
  15. 15. Code Smell
  16. 16. Baixa coesão e Alto acoplamento são um dos fatores fundamentais para aumentar a dependência,dificultar a manutenção, expansão e alteração.
  17. 17. 1° Code Smell
  18. 18. Rigidez“O sistema é difícil de mudar, porque cada vez que você muda alguma coisa, vocêtem que mudar alguma outra coisa em uma sucessão interminável de mudanças.”
  19. 19. 2° Code Smell
  20. 20. Fragilidade“Uma mudança de uma parte do sistema faz com que ele quebra em muitas outras partes, completamente alheios.”
  21. 21. 3° Code Smell
  22. 22. Imobilidade“É difícil separar o sistema em componentes que podem ser reutilizados em outros sistemas.”
  23. 23. 4° Code Smell
  24. 24. Complexidade Desnecessária“Há muitas estruturas de código muito inteligentes que não são necessárias agora, mas poderia ser muito útil um dia.”
  25. 25. 5° Code Smell
  26. 26. Repetições Inúteis“O código parece que foi escrito por dois programadores chamado Recortar e Colar.”
  27. 27. Mostra aí como combater esse tal de Code Smell
  28. 28. Qualidade de Código boas práticas, princípios e padrões.
  29. 29. Início Teste unitário Princípios de Projeto OOCódigo Refatoração POO Padrões de Projeto OO Integração Contínua
  30. 30. Desenvolvimento Dirigido pelos Testes
  31. 31. Programação em Par
  32. 32. Refatoração
  33. 33. Substitua Herança por DelegaçãoExemplo: pilha subclasse de vetor.Class MyStack extends Vector { public void push (Object element) { insertElementAt (element, 0);} public Object pop () { Object result = firstElement (); removeElementAt (0); return result;}
  34. 34. Refatorando...Crio campo para superclasse.Class MyStack extends Vector { private Vector _vector = this; public void push (Object element) { _vector.insertElementAt (element, 0);} public Object pop () { Object result = _vector.firstElement (); _vector.removeElementAt (0); return result;}
  35. 35. Refatorando...Removo herança.Class MyStack extends Vector { private Vector _vector = this; new Vector (); public void push (Object element) { _vector.insertElementAt (element, 0); } public Object pop () { Object result = _vector.firstElement (); _vector.removeElementAt (0); return result; }
  36. 36. Acoplamento e Coesão DiminuirAcoplamento Aumentar Coesão
  37. 37. Programação Orientada a Objetos Abstração Encapsulamento Reuso Herança Polimorfismo
  38. 38. Princípios de Projeto •Restrição ao Acesso •Prefira a composição à herança •Programação para a interface •Separe o que permanece igual do que varia
  39. 39. S ingle Responsibility Principle (SRP)O pen/Closed Principle (OCP)L iskov substitution principle (LSP)I nterface Segregation Principle (ISP)D ependency Inversion Principle (DIP)
  40. 40. Princípios de Projeto OO – Single Responsibility Principle (SRP) "Nunca deve haver mais de um motivo para uma classe ser alterada"
  41. 41. Violação do princípio: Considere a Classe TAD
  42. 42. Adequação ao princípio:
  43. 43. Princípios de Projeto OO – Open/Closed Principle (OCP)“As entidades devem estar abertas para extensão, mas fechadas para modificação”
  44. 44. Violação do princípio:Considere o método para calcular o preço total de peças: public double totalPrice(Part[] parts){ double total = 0.0; for(int i=0; i < parts.length; i++){ total += parts[i].getPrice(); } return total; }O método processa diferentes tipos de peças da hierarquia de Part, sem demandar modificações, portanto conformado- se com o OCP.
  45. 45. Violação do princípio:O que ocorrerá se a empresa decidir cobrar um preço adicional por certas peças? public double totalPrice(Part[] parts){ double total = 0.0; for(int i = 0; i < parts.length; i++){ if(parts[i] instanceof Motherbord) total +=(1.45 * part[i].getPrice()); else if (parts[i] instanceof Memory) total += (1.30 * part[i].getPrice()); else total += part[i].getPrice(); } return total; }
  46. 46. Adequação ao princípio:Considere novamente o método totalPrice original public double totalPrice(Part[] parts){ double total = 0.0; for(int i = 0; i < parts.length; i++){ total += part[i].getPrice(); } return total; }Note que agora o método não precisa ser alterado para processar diferentes tipos de peças.Mas as subclasses especiais de Parts precisam
  47. 47. Adequação ao princípio:public class Part{ private double basePrice; public void setPrice(double price){ basePrice = price; } public double getPrice(){return basePrice;}}public class motherBoard extends Part{ public double getPrice(){return 1.45*super.getPrice();}public class Memory extends Part{ public double getPrice(){ return 1.30 * super.getPrice(); }}
  48. 48. Princípios de Projeto OO – Liskov substitution principle (LSP)“Funções que usam objetos de uma superclasse devem ser capazes de usar objetos das subclasses.”
  49. 49. Princípios de Projeto OO – Interface Segregation Principle (ISP) “Interfaces mais específicas melhor que interface de propósito diversos.”
  50. 50. Princípios de Projeto OO – Dependency Inversion Principle (DIP) “Módulos de alto nível não devem depender de módulos de nível mais baixo. Todos devem depender de abstrações.”
  51. 51. Padrões de Projeto
  52. 52. Padrões Arquiteturais De acordo com oscondutores arquiteturais
  53. 53. Atender ao negócio Usuário FelizNecessidade atendida $$$$$$$$$
  54. 54. @edgarddavidsonhttp://edgarddavidson.com

×