Porque você teria a lógica de implementação e a lógica de negócios misturado.
Algo que quebraria algumas regras de legibilidade e faria com que você perdesse mais tempo procurando onde corrigir ou alterar algumas lógica do que realmente resolvendo o problema
Não entendi.
Vamos imaginar que eu tenha essas funções:
function isAllowedOverbooking() {}
function isAllowedSomethingElse() {}
function makeBooking(isAllowedFn) {
if(isAllowedFn()) {}
}
como isso ficaria misturado? que regras de legibilidades são essas?
e porque separar numa classe essa política? sendo que não está sendo utilizada em nenhum outro lugar?
se tiver um bug no makeBooking, como separar essa política vai ajudar a encontrar o bug? acredito que testes já resolveriam isso.
vamos por dúvidas:
> como isso ficaria misturado?
Vou usar esse exemplo javascript para demonstrar
**Bad pratice**
```javascript
function makeBooking(cargo, voyage) {
// Lógica de negócios e implementação misturadas
let maxBooking = voyage.capacity * 1.1;
if ((voyage.bookedCargoSize + cargo.size) > maxBooking)
return -1;
let confirmation = orderConfirmationSequence.next();
voyage.addCargo(cargo, confirmation);
return confirmation;
}
```
Neste exemplo ocorre a mistura da lógica de implementação e da lógica de negócio, o que dificultaria cada parte do código de ser testado. Ao mesmo tempo que fere o principio do S.O.L.I.D que é explicado nesse [vídeo do Deschamps](https://youtu.be/6SfrO3D4dHM).
Outro problema é que provavelmente você queira usar este trecho do código em outras partes do código mas com ele hard-code fica dificil.
Do outro lado temos este código seguindo a good pratice
```javascript
class OverbookingPolicy {
constructor(overbookingRate) {
this.overbookingRate = overbookingRate;
}
isAllowed(cargo, voyage) {
let maxBooking = voyage.capacity * this.overbookingRate;
return ((voyage.bookedCargoSize + cargo.size) <= maxBooking);
}
}
function makeBooking(cargo, voyage, policy) {
if (!policy.isAllowed(cargo, voyage))
return -1;
let confirmation = orderConfirmationSequence.next();
voyage.addCargo(cargo, confirmation);
return confirmation;
}
```
Este código já automaticamente deixa o código menor, mais testável e mais reusável que o anterior já que eu consigo reutilizar a classe em outros pontos.
---
> Que regras de legibilidades são essas?
Essas regras são o que chamamos de [Clean Code](https://youtu.be/O5aWwBXPoh4) baseado num livro de mesmo nome.
Essas regras de legibilidade tentam tornar o código mais simples de entender para outros programadores, normalmente quando você está escrevendo o seu código tudo parece muito mais fácil de entender do que quando um terceiro vai tentar ler ou mesmo você no futuro.
E acredite, clean code não é a única regra de legibilidade. Existe o D.R.Y que é sigla para Don't repeat Yourself, K.I.S.S que é sigla para Keep It Simple Stupid, Y.A.G.N.I que é sigla para You Ain't Gonna Need It, entre outros ... dependendo claro de projeto a projeto.
**Bad Pratice**
```javascript
function clc(a, b, c, d) {
var res = a * b + c - d;
return res;
}
var r = clc(2, 3, 4, 1);
console.log(r);
```
**Good Pratice**
```javascript
function calculateResult(multiplier, multiplicand, addend, subtrahend) {
var result = (multiplier * multiplicand) + addend - subtrahend;
return result;
}
var finalResult = calculateResult(2, 3, 4, 1);
console.log(finalResult);
```
> e porque separar numa classe essa política? sendo que não está sendo utilizada em nenhum outro lugar?
Quanto se separa uma classe em uma política (no caso de strategy), você aumenta a testabilidade do código e começa a seguir um principio chamado príncipio de responsábilidade única. Ao mesmo tempo que encapsula sua lógica fazendo com que a lógica de negócio fique independente da lógica de implementação.
> se tiver um bug no makeBooking, como separar essa política vai ajudar a encontrar o bug? acredito que testes já resolveriam isso.
Você está correto na parte do que testes já resolveriam isso, mas separar a lógica ainda ajuda no quesito de que você simplifica a refatoração e aumenta a testabilidade independente de cada um dos componentes
>
SOLID é mais genérico do que remédio de farmácia. Esse princípio não ajuda em nada.
Além disso eu dei um exemplo de código pra você me explicar o que tinha de errado mas você usou o seu exemplo anterior.