Ho letto in generale che avere molti (4) argomenti per una funzione / costruttore è una cattiva pratica. Questa è ancora considerata una cattiva pratica? [chiuso]

Ho diversi test sull'odore per le "migliori pratiche". Alcuni vengono attraverso cattive implementazioni o strumenti deboli. Alcuni aiutano le nostre menti imperfette a creare cose di alta qualità. Alcuni sono identificati dalle correlazioni tra codice e bug (anche se la causalità potrebbe non essere mai dimostrata). Quindi mi piace capire che cosa sta contribuendo a una regola.

È chiaro che molti parametri possono diventare una sfida di usabilità.

Tuttavia, consente di testare alcuni criteri più rigidi.

Un sacco di sistemi eseguono transazioni CRUD su database relazionali.

Quindi, un test è "questa" regola delle migliori pratiche "influirà sulle transazioni CRUD dei codici in modo positivo o negativo?"

Dopo tutto, anche se potrebbe non piacerti il mio benchmark, i database relazionali sono pensati per rappresentare blocchi del mondo reale in robusti modi di transazione ACID.

Costruire relazioni incomplete, che non rappresentano lo stato del mondo reale, è solitamente "una brutta cosa". Crea una complessità extra per supportarlo, senza alcun apparente pay-off.

Questa non è una licenza per ignorare i "tipi corretti". Se le parti del costruttore o dell'elenco dei parametri di funzione contengono i valori di tipi reali significativi, che rappresentano qualcosa di rilevante nel dominio, che ha un comportamento nell'applicazione, devono essere costruiti o passati.

AFAIK, tutti i linguaggi funzionali forniscono esplicitamente meccanismi per rappresentare e costruire "relazioni appropriate", e questa è "una buona cosa".

Quindi accetto che esistano dei problemi di usabilità semplici e ragionevoli, che non dovrebbero essere ignorati.

Tuttavia, nel caso di un linguaggio funzionale '> 4' non sembra utile. L'immutabilità è un "martello" molto più grande per risolvere i problemi. Per me, rappresenta correttamente lo stato della realtà, trumps '> 4' ogni volta.

1. Sì. Il numero di possibili permutazioni per gli argomenti n scala piuttosto rapidamente . È facile dimenticare l'ordine degli argomenti in una funzione di arity 5. Inoltre, c'è una buona probabilità che alcuni di questi argomenti sono sempre usati insieme. Il loro avvolgimento rende più facile il loro passaggio (ed è necessario per restituirli dalle funzioni).

2. Non ha familiarità con Scala, ma le classi anonime potrebbero essere utili poiché l'ordine dei campi non è importante.

Scala case classes sono molto simili a tuple immutabili (più altre cose irrilevanti per questa domanda). Non trovo strana una tupla con più di 4 elementi, anche se c'è sicuramente un limite in cui inizia a diventare illeggibile.

Inoltre, poiché una classe di case come Person(name: String, age: Int) è immutabile, alcuni dei modelli di Java per la creazione di oggetti complessi come il pattern Builder diventano difficili da applicare. Vedi Qual è l'equivalente Scala di un modello di builder Java? e Pattern di builder sicuro in Scala .

Non l'ho mai sentito.

Che cosa ti aspetti di fare se devi passare sia un nome utente sia un permesso di sicurezza specifico? Dovresti creare una nuova classe in grado di contenere entrambi, popolarla e quindi inviarla per mantenere "less is better" per quanto riguarda i parametri? Non riesco a immaginare che questo possa essere vero.

Anche le librerie ossessionate dalle prestazioni (jQuery, php, .NET) hanno più argomenti nelle loro funzioni.

Penso che la mia risposta abbia avuto più senso prima che l'OP abbia modificato la sua domanda per includere solo i parametri di > 4. La mia risposta è valida se ci sono solo 2 parametri o così.

Se ci sono > 4 parametri ... sì, dovresti rivalutare ciò che stai facendo e considerare se tutti i parametri sono effettivamente necessari o se può essere passato un oggetto più comprensivo.

Il problema è duplice.

In caso di funzioni / metodi:

• Il dover passare molti parametri è un'indicazione di un design non coeso.
• Il metodo non usa lo stato della classe.
• Se si tratta di un metodo statico in una classe di utilità statica, è OK. Altrimenti è un possibile indicatore che il metodo non appartiene a quella classe.
• Anche nel caso di un metodo statico, puoi evitare molti parametri creando un "oggetto parametro" che è una classe con tutti i valori necessari per passare al metodo.

In caso di costruttore:

• Puoi utilizzare l'oggetto parametro " che ho menzionato sopra
• Oppure puoi popolare l'oggetto con i metodi setter . In questo caso, devi fornire "valori predefiniti intelligenti" in modo che l'oggetto abbia uno stato predefinito che inizia o genera un'eccezione di stato non valida se chiami un metodo che richiede l'oggetto essere completamente inizializzato.