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

Post on 24-May-2015

5.199 views 2 download

Transcript of qualidade de código: boas práticas, 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