Passando singolo oggetto vs. passando più parametri

Question

Supponiamo che io ho il seguente

Class A { 
    Foo getFoo(); 
    Bar getBar(); 
    Baz getBaz(); 
} 

e ho bisogno di definire una funzione che utilizza doStuffFoo, Bar, Baz di uno oggetto e fa alcune cose

Sto lottando tra quale metodo di implementazione doStuff è meglio (supponiamo che sarebbe indesiderabile inserire doStuff all'interno della classe A)

Metodo A

void doStuff(Foo foo, Bar bar, Baz baz) 
{ 
    //some operation 
} 

o

Metodo B

void doStuff(A a) 
{ 
    Foo foo = a.getFoo(); 
    Bar bar = a.getBar(); 
    Baz baz = a.getBaz(); 
    //some operation 
} 

A mia conoscenza limitata, (+ pro, - contro)

Me THOD Un

+ E 'chiaro esattamente quali parametri doStuff() opera su

-Susceptible a elenchi di parametri lunghe e più suscettibili di errori degli utenti

Metodo B

+ Semplice, facile da utilizzare il metodo

+ Sembra più estensibile (?)

-crea inutile dipendenza nei confronti della classe A

---

Può chiunque quota di ulteriori indizi verso i pro ei contro di questi due metodi?

Answer 1

Metodo A (parametri nudi) ha sempre i vantaggi che

• che richiede il metodo autore di digitare meno, dal momento che non c'è bisogno di implementare un oggetto Parameter,
• che richiede il metodo chiamante di digitare meno, dal momento che non c'è bisogno di creare un'istanza di un oggetto Parameter
• si comporta meglio, dal momento che nessun oggetto parametro deve essere costruita e garbage collection
• il lettore può vedere ciò che i singoli parametri sono dalla firma del metodo da solo (ma t la sua è un'arma a doppio taglio; vedi sotto)

Metodo B (Parameter Object) presenta vantaggi quando

• i parametri hanno un significato dominio come un gruppo, in modo che l'Object parametro può essere dato un nome che spiega quel significato, salvando il lettore dal dovendo leggere e capire ogni membro del gruppo e come si collegano
• l'elenco dei parametri viene utilizzato in più di un metodo, quindi utilizzando l'Oggetto Parametro in ciascuna riduzione della duplicazione
• i valori nell'elenco parametri vengono passati in giro tra più m ethods come gruppo, che è più facile quando possono essere passati come un singolo oggetto parametro
• alcune combinazioni di valori non sono valide; l'oggetto parametro può impedire quelle combinazioni
• alcuni valori sono opzionali, che possono essere fornite dall'oggetto parametri, invece di (a seconda della lingua) i valori dei parametri di default o metodi di overload
• c'è più di un parametro dello stesso tipo , facendo errori dei valori-swapping più probabile (anche se un oggetto parametro non è migliore in questo caso se si ha un costruttore con la stessa lista di parametri come il metodo)

che l'oggetto parametro introduce una nuova dipendenza su cui caller e callee dipendono non è uno svantaggio in quanto è una classe semplice senza dipendenze.

Quindi, parametro dell'oggetto è

• quasi mai la pena per un singolo parametro, a volte vale la pena per un metodo a due parametri (ad esempio Point di solito è meglio di x, y) e volte no, e sempre disponibile con tre e più parametri
• sempre più utile quando più metodi utilizzano lo stesso elenco di parametri

Answer 2

Parameter Object s forniscono un approccio piacevole per incapsulare related parametri per ridurre il Parame totale contare su qualsiasi metodo o costruttore. Si dovrebbe fare molta attenzione per assicurarsi che gli oggetti parametro contengano effettivamente parametri veramente correlati.

In realtà ci sono diversi modi di affrontare questo problema a seconda dello parameter types con cui si ha a che fare. Se si hanno a che fare con parametri di tipo generale come più di uno String se Int s e c'è il potenziale che un client passi effettivamente la sequenza errata di argomenti, spesso è più logico creare custom types.creare enum con possibili valori. Questo può fornire un buon controllo del tempo di compilazione per i tuoi argomenti. Un altro buon uso di questi è che è possibile utilizzarli per i valori complessi delle funzioni da return. Vedi here.

Un altro approccio che prendo un sacco di volte è controllare e vedere se il lavoro svolto dal metodo doStuff è suddiviso in metodi più semplici con meno dipendenze.

Principalmente provo a seguire la raccomandazione di Bob Martin di un massimo di tre parametri. Beh, in realtà dice che dovrebbe essere per lo più non più di uno! Qualsiasi aumento dovrebbe avere giustificati motivi. Segnala questo libro eccellente: Clean Code