Bem fiz a tradução desse artigo Anti-IF.
O problema básico é que o IF cria dependências, o acoplamento entre os módulos (métodos, objetos, componentes, etc) e aumenta os caminhos possíveis dentro do nosso código (o que reduz a legibilidade).
Um IF parece ser uma maneira rápida e fácil de fazer mudanças, mas pelos motivos listados acima, se após o IF, criamos software cheio de duplicações que não pode ser modificado.
Aqui está um exemplo simples:
double calculateValue() {
// look is here
if(_type == BTP) {
return calculateBTPValue();
// look is here
} else if(_type == BOT) {
return calculateBOTValue();
} else {
return calculateEUBValue();
}
}
Toda mudança no tipo de vínculo, por exemplo, um novo laço para avaliar, conduz a uma modificação no nosso pedaço de código. Imagine o que seria necessário fazer para modificar os métodos com CASES e IF’s e suas opções!
double calculateValue() {
_bondProfile.calculate();
}
// AbstractBondProfile class
//
// look is here
abstract double calculate();
// classe BTPBondProfile >> AbstractBondProfile
double calculate() {
...
}
// classe BOTBondProfile >> AbstractBondProfile
double calculate() {
...
}
// classe EUBondProfile >> AbstractBondProfile
double calculate() {
...
}
O que ganhamos tirando IF?
A vantagem é que, amanhã, podemos atender a solicitação para um novo tipo de ligação, basta criar uma nova classe, com a única lógica necessária para calcular o valor do novo Bond.
A solução não é sempre criar uma nova classe abstrata ou uma interface. Mas a solução será sempre fazer o software flexível, comunicativo, testável, prontos para a mudança.
