Sto osservando il modello di builder per aiutare a impostare dipendenze e parametri che potrebbero richiedere una logica complessa per una classe. Ma dagli esempi che ho visto, il modello di builder non sembra molto verificabile. Esempio che ho preso da qui :
public static class Builder {
private long accountNumber; //This is important, so we'll pass it to the constructor.
private String owner;
private String branch;
private double balance;
private double interestRate;
public Builder(long accountNumber) {
this.accountNumber = accountNumber;
}
public Builder withOwner(String owner){
this.owner = owner;
return this; //By returning the builder each time, we can create a fluent interface.
}
public Builder atBranch(String branch){
this.branch = branch;
return this;
}
public Builder openingBalance(double balance){
this.balance = balance;
return this;
}
public Builder atRate(double interestRate){
this.interestRate = interestRate;
return this;
}
public BankAccount build(){
//Here we create the actual bank account object, which is always in a fully initialised state when it's returned.
BankAccount account = new BankAccount(); //Since the builder is in the BankAccount class, we can invoke its private constructor.
account.accountNumber = this.accountNumber;
account.owner = this.owner;
account.branch = this.branch;
account.balance = this.balance;
account.interestRate = this.interestRate;
return account;
}
}
Tutte le funzioni restituiscono il builder e impostano i membri privati nella classe builder, quindi è difficile verificare se le funzioni sono corrette. In questo caso, forse va bene perché la logica del setter è molto semplice, quindi non ha bisogno di essere testata. Ma cosa succederebbe se le funzioni dovessero svolgere un lavoro più complesso per impostare il parametro per la classe in costruzione? Ad esempio, supponiamo che la funzione riceva un elenco e debba filtrare e raggruppare alcuni valori per creare un dizionario.
In che modo viene comunemente testato il pattern del builder?
Possibili modi per renderlo più testabile:
-
Sposta tutta la logica in un'altra classe e il costruttore chiama semplicemente quella classe. Il lato negativo è che rende il builder molto meno utile.
-
Provalo per deduzione attraverso la classe che si sta costruendo. Ma questo diventa più di un test di integrazione e può diventare molto complesso.