O documento discute boas práticas de qualidade de código, incluindo princípios como baixo acoplamento e alta coesão. Também aborda padrões de projeto orientado a objetos e códigos cheirosos, além de técnicas como teste unitário e refatoração para melhorar a qualidade do código.

1. Qualidade de Código:
boas práticas,
princípios e
padrões.
@edgarddavidson
http://edgarddavidson.com

3. Curso de Pós Graduação em
Engenharia de Software Centrada em Métodos Ágeis
http://engenhariadesoftwareagil.com

4. Curso de Pós Graduação em
Teste e Qualidade
de Software
http://testeequalidadedesoftware.com

5. Referências

6. <trollagem>

7. Um típico implementador
de POG convícto

8. 1°encontro dos
implementadores de POG
convíctos

9. Projeto entregue pelos
implementadores de POG
convíctos

10. Um dia típico de trabalho de um
implementador de POG convícto

11. Implementadores de POG convíctos
também trabalham em equipe

12. Um implementador de POG convícto
não tem medo do perigo

13. Um implementador de POG convícto
assume que boas práticas,
princípios e padrões
é tudo um VIAGEM

14. Por algum
motivo os
erros se
repetem

15. </trollagem>

16. Code Smell

17. 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.

18. 1° Code Smell

19. 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.”

20. 2° Code Smell

21. Fragilidade
“Uma mudança de uma parte do sistema faz com que ele quebra em muitas outras partes,
completamente alheios.”

22. 3° Code Smell

23. Imobilidade
“É difícil separar o sistema em componentes que podem ser reutilizados em outros sistemas.”

24. 4° Code Smell

25. 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.”

26. 5° Code Smell

27. Repetições
Inúteis
“O código parece que foi escrito por dois programadores chamado Recortar e Colar.”

28. Mostra aí como combater
esse tal de Code Smell

29. Qualidade de Código
boas práticas,
princípios e
padrões.

30. Início
Teste
unitário
Princípios de
Projeto OO
Código
Refatoração
POO
Padrões de
Projeto OO
Integração Contínua

32. Desenvolvimento Dirigido pelos Testes

33. Programação em Par

34. Refatoração

35. Substitua Herança por Delegação
Exemplo: 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;
}

36. 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;
}

37. 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;
}

38. Acoplamento e Coesão
Diminuir
Acoplamento
Aumentar
Coesão

39. Programação Orientada a Objetos
Abstração
Encapsulamento
Reuso
Herança
Polimorfismo

40. 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

41. 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)

42. Princípios de Projeto OO – Single Responsibility Principle (SRP)
"Nunca deve haver mais de um motivo para uma classe ser
alterada"

43. Violação do princípio:
Considere a Classe TAD

44. Adequação ao princípio:

45. Princípios de Projeto OO – Open/Closed Principle (OCP)
“As entidades devem estar abertas para extensão, mas fechadas
para modificação”

46. 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.

47. 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;
}

48. 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

49. 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();
}
}

50. 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.”

51. Princípios de Projeto OO – Interface Segregation Principle (ISP)
“Interfaces mais específicas melhor que interface de
propósito diversos.”

52. 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.”

53. Padrões de Projeto

54. Padrões Arquiteturais
De acordo com os
condutores arquiteturais

55. Atender ao negócio
Usuário Feliz
Necessidade atendida
$$$$$$$$$

56. @edgarddavidson
http://edgarddavidson.com