Qualidade de Código: boas práticas, princípios e @edgarddavidson http://edgarddavidson.com princípios e padrões.
Qualidade de Código:boas práticas,
princípios e
@edgarddavidsonhttp://edgarddavidson.com
princípios e padrões.
Curso de Pós Graduação em
http://engenhariadesoftwareagil.com
Engenharia de Software Centrada em Métodos Ágeis
Curso de Pós Graduação em Teste e Qualidade
http://testeequalidadedesoftware.com
Teste e Qualidade de Software
Referências
<trollagem>
Um típico implementador
de POG convícto
1°encontro dos
implementadores de POG
convíctos
Projeto entregue pelos
implementadores de POG
convíctos
Projeto entregue pelos
implementadores de POG
convíctos
Um dia típico de trabalho de um
implementador de POG convícto
Implementadores de POG convíctos
também trabalham em equipe
Um implementador de POG convícto
não tem medo do perigo
Um implementador de POG convícto
assume que boas práticas,
princípios e padrões
é tudo um VIAGEMé tudo um VIAGEMé tudo um VIAGEMé tudo um VIAGEM
Por algum
motivo os
erros se
repetem
</trollagem>
Code Smell
Baixa coesãoe
Alto acoplamento
são um dos fatores fundamentais são um dos fatores fundamentais para aumentar a dependência,
dificultar a manutenção, expansão e alteração.
1° Code Smell
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.”
2° Code Smell
Fragilidade
“Uma mudança de uma parte do sistema faz com que ele quebra em muitas outras partes, completamente alheios.”
Fragilidade
3° Code Smell
Imobilidade
“É difícil separar o sistema em componentes que podem ser reutilizados em outros sistemas.”
4° Code Smell
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.”
Desnecessária
5° Code Smell
Repetições
InúteisInúteis
“O código parece que foi escrito por dois programadores chamado Recortar e Colar.”
Mostra aí como combater esse tal de Code Smell
Qualidade de Códigoboas práticas,
princípios e padrões.padrões.
Testeunitário
Testeunitário
Código POO
Código POO RefatoraçãoRefatoração
Princípios de Projeto OO
Princípios de Projeto OO
Início
Integração ContínuaIntegração Contínua
POOPOO
Padrões de Projeto OOPadrões de Projeto OO
Desenvolvimento Dirigido pelos Testes
Programação em Par
Refatoração
Substitua Herança por DelegaçãoExemplo: pilha subclasse de vetor.Class MyStack extends Vector {
public void push (Object element) {public void push (Object element) {
insertElementAt (element, 0);
}
public Object pop () {
Object result = firstElement ();
removeElementAt (0);
return result;
}
Refatorando...Crio campo para superclasse.Class MyStack extends Vector {
private Vector _vector = this;
public void push (Object element) {public void push (Object element) {
_vector.insertElementAt (element, 0);
}
public Object pop () {
Object result = _vector.firstElement ();
_vector.removeElementAt (0);
return result;
}
Refatorando...Removo herança.Class MyStack extends Vector {
private Vector _vector = this; new Vector ();
public void push (Object element) {public void push (Object element) {
_vector.insertElementAt (element, 0);
}
public Object pop () {
Object result = _vector.firstElement ();
_vector.removeElementAt (0);
return result;
}
Acoplamento e Coesão
Diminuir Acoplamento
AumentarCoesão
Programação Orientada a Objetos
AbstraçãoEncapsulamento
ReusoHerança
Polimorfismo
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
SOL
ingle Responsibility Principle (SRP)
pen/Closed Principle (OCP)
iskov substitution principle (LSP)LID
iskov substitution principle (LSP)
nterface Segregation Principle (ISP)
ependency Inversion Principle (DIP)
Princípios de Projeto OO – Single Responsibility Principle (SRP)
"Nunca deve haver mais de um motivo para uma classe ser alterada"
Violação do princípio:Considere a Classe TAD
Adequação ao princípio:
Princípios de Projeto OO – Open/Closed Principle (OCP)
“As entidades devem estar abertas para extensão, mas fechadas para modificação”
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();
Violação do princípio:
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.
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)
Violação do princípio:
if(parts[i] instanceof Motherbord)total +=(1.45 * part[i].getPrice());
else if (parts[i] instanceof Memory)total += (1.30 * part[i].getPrice());
elsetotal += part[i].getPrice();
}return total;
}
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();}
Adequação ao princípio:
}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
public class Part{
private double basePrice;
public void setPrice(double price){
basePrice = price;
}
public double getPrice(){return basePrice;}
}
Adequação ao princípio:
}
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();
}
}
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.”
Princípios de Projeto OO – Interface Segregation Principle (ISP)
“Interfaces mais específicas melhor que interface de propósito diversos.”
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.”
Padrões de Projeto
Padrões Arquiteturais
De acordo com os condutores arquiteturais
Atender ao negócioUsuário Feliz
Necessidade atendida$$$$$$$$$
@edgarddavidsonhttp://edgarddavidson.com