Builder Pattern vs Struttura come parametro

Question

Se una classe ha troppi parametri nel costruttore, possiamo usare una struttura o un modello di costruttore.

Che è migliore? C'è qualche buona pratica?

Answer 1

Usa una classe con una struttura che soddisfi le tue esigenze. Martin Fowler ha una tecnica simile chiamata DataTransferObject (DTO), in cui si passa un modello a oggetti invece di recuperare i dati utilizzando più chiamate (chiamate di database in modo perseumibilmente), riducendo il costo.

Il beneficio su Builder Pattern:

1. La struttura della classe non ha una logica aggiuntiva, significa che è più facile da leggere (meno logica)
2. Non creare costruttore che fa vere opere Odore del codice, di nuovo il codice più facile da leggere
3. L'operazione è economica, dal momento che passa solo i riferimenti e non crei un oggetto nuovo di zecca. Soprattutto quando la struttura dei dati è grande.

Il rovescio della medaglia: l'oggetto è in stato mutabile.

Answer 2

Dipenderebbe da quali fossero i parametri e dalla loro relazione reciproca e da quanti sono richiesti rispetto al opzionale.

Se sono correlati diversi parametri, di solito è meglio creare una classe (o struttura) separata per archiviare tali parametri.

Per esempio invece di

TransferMoney(long srcAccountNumber, int srcAmount, Currency srcCurrency, long destAccountNumber)

Possiamo vedere che AMMOUNT SRC e SrcCurrency sono correlati e possiamo creare una nuova classe per gestire il denaro di vari importi (e possibilmente aggiungere metodi per la conversione in altre valute ecc.) E ridurre il numero di parametri:

TransferMoney(long srcAccountNumber, Money amount, long destAccountNumber)

Questa domanda è agnostica del linguaggio, ma se avevi una lingua che non supporta i valori predefiniti (come Java), potrebbe essere necessario disporre di diversi metodi sovraccarichi con numeri e tipi diversi di parametri per adattarsi a tutte le possibili combinazioni. Se ci sono molte combinazioni, allora un costruttore è un modo più pulito da percorrere.