I "troppi parametri" sono un problema visivo o logico?

Question

I "troppi parametri" sono un problema visivo o logico?

#1 da (22 voti)
#2 da (1 voti)

7

secondo Ci sono linee guida su quanti parametri una funzione dovrebbe accettare? , un metodo non dovrebbe avere troppi parametri. Tuttavia, alcune risposte suggeriscono che questo problema può essere risolto dal modello di builder:

Builder b=new Builder();
b.setParm1("a");
b.setParm2("b");
.
.
.
Obj obj=b.createObj();

o incapsula i parametri in un singolo oggetto.

ObjectParam op=new ObjectParam();
op.param1="a";
op.param2="b";
.
.
.
obj.f(op);

Ma dubito che risolva il problema, perché penso che i metodi per allineare semplicemente i parametri in modo migliore (cioè: da orizzontale a verticale), ma non cambia la natura che le attività dipendono da troppi parametri . E se voglio che la catena di parametri abbia un aspetto migliore, posso usare una nuova riga per ogni parametro come:

link

quindi la mia domanda è, i "troppi parametri" sono un problema visivo (difficile leggere una lunga riga di codice), o un problema logico (la natura dell'attività dipende da troppi parametri e necessità di interruzione)? Se si tratta più di un problema visivo, una nuova riga per ogni parametro risolve il problema?

coding-style parameters

posta mmmaaa 21.03.2018 - 07:19

fonte

2 risposte

1

Un metodo che prende molti parametri è essenzialmente un passo nella direzione opposta dall'approccio convenzione sulla configurazione , che si concentra Intorno alla semplificazione di tali chiamate senza perdere la capacità di modificare i valori secondo le necessità attraverso l'uso di default sensibili.

In altre parole, chiaramente non vuoi perdere flessibilità, ma quasi sicuramente non hai bisogno che ogni singolo parametro sia passato dinamicamente. Probabilmente un buon numero di parametri sarà fisso / statico. Prendi un programma zip come esempio. Sì, forse potresti voler modificare l'algoritmo di compressione, il livello di compressione, il numero di core della CPU da dedicare all'attività, .. qualunque sia. Il punto è che nessuno vuole specificare tutti questi parametri ogni volta che è necessario creare un file zip, riducendo efficacemente una chiamata fornendo gli elementi essenziali (ad esempio il nome del file zip di destinazione, i file da aggiungere al file zip).

I motivi per cui utilizzi la convenzione sull'approccio di configurazione sono gli stessi motivi per cui non dovresti avere metodi che richiedono molti parametri. In breve, la semplicità è buona.

risposta data 21.03.2018 - 08:28

fonte

Leggi altre domande sui tag coding-style parameters

Perché la gente mette '\ n' all'inizio delle stringhe? Aggressivo aggiornamento automatico?

score 22 · Accepted Answer

È prima di tutto un problema logico (che spesso si presenta anche con problemi visivi). La soluzione sbagliata è provare solo a migliorare il problema visivo

encapsulate parameters in a single object [...] just align the parameters at better way (i.e.:from horizontally to vertically)

L'incapsulamento di parametri in un oggetto non significa mettere cinque parametri in un contenitore arbitrario con un nome privo di significato come ObjectParam . Invece, incapsulare un gruppo di parametri in un oggetto dovrebbe creare una nuova astrazione (o riutilizzarne uno esistente). Mi piace

che incapsula tre parametri "X, Y, Z" in un parametro "posizione di tipo Point3D o
parametri di incapsulamento "startDate, endDate" in un oggetto DateInterval o
incapsulamento dei parametri documentTitle, documentText, author in un oggetto Document che raggruppa questi parametri insieme

Se il metodo in palio ha molti parametri non correlati, non è possibile trovare un buon nome di raggruppamento, quindi probabilmente ha troppi parametri e troppe responsabilità.