Qual è l'alternativa al codice DRY quando richiede troppi parametri?

Senza vedere alcun codice, è difficile dare consigli precisi per la tua situazione. Tuttavia, è probabile che la tua situazione evidenzi il modo in cui ASCIUGA è il nemico dei BACI e l'accoppiamento lento. Per ridurre la duplicazione, hai creato una serie di funzioni condivise. Quelle funzioni hanno bisogno di molti parametri e probabilmente sono usate in molti posti. Quindi sono ora più complessi di quanto avrebbero potuto essere se il codice fosse ripetuto e accoppiasse molte parti della vostra applicazione a quelle funzioni.

DRY non è una regola dura e veloce. È una delle molte linee guida per creare codice migliore. Tuttavia, deve essere bilanciato con altre linee guida in conflitto. Se una piccola ripetizione riduce la complessità e l'accoppiamento, allora optare per una piccola ripetizione.

Il solito consiglio per evitare di ripetere lo stesso set di parametri più e più volte è di trasformare parametri che appaiono solo insieme in una classe e passare un oggetto di quella classe invece di una lista di valori. Va perfettamente bene creare un tipo di classe che serva semplicemente a rendere il tuo codice più secco in questo modo.

Sembra che tu abbia il vincolo aggiunto che lo stesso insieme di parametri deve scorrere attraverso il codice scritto in lingue diverse. Ciò rende le cose più difficili, ma fintanto che questi valori continuano ad apparire insieme è spesso possibile scrivere quella struttura una volta sola e quindi generare automaticamente classi / strutture in lingue diverse da quella singola dichiarazione. Dovresti pubblicare maggiori dettagli sul tuo sistema per decidere se è possibile o utile.

Il linguaggio di programmazione Haskell aveva in realtà un problema simile con la sua "sintassi dei record" per le strutture di dati, dove potreste aggiornare il terzo campo di una struttura dati con cose come:

incrementCount MyRecord{param1=p1, param2=p2, count=c, param3=p3} = MyRecord{
        param1=p1, param2=p2, count=c+1, param3=p3}

Ciò è stato risolto aggiungendo alcune caratteristiche sintattiche a livello di lingua che assomigliano più ad aggiornare un dizionario:

incrementCount m@MyRecord{count=c} = m{count = c + 1}

Qui la sintassi m@<pattern> ora supporta un "pattern parziale" e il parametro count nel record può essere referenziato e aggiornato in modo specifico. Uno dei problemi più grandi che risolve è che non è più necessario aggiornare ogni singola funzione che gestisce la struttura dati, semplicemente perché è stata aggiornata la definizione della struttura dati per, ad esempio, rinominare i parametri chiave o aggiungine di nuovi.

Puoi farlo anche tu! Hai solo bisogno di passare tutti i parametri come un dizionario dei parametri condivisi; invece di function (url, queryParams, handlingNotes, ...) puoi iniziare a standardizzare su un oggetto richiesta {url: u, queryParams: q, handlingNotes: h, ...}. Ogni funzione che gestisce l'oggetto richiesta si preoccuperà solo del sottoinsieme ristretto a cui tiene conto e passerà gli altri parametri direttamente, senza bisogno di codice standard .

TL; DR: incapsula gli argomenti comuni o salva stato utilizzando applicazione parziale o istanza oggetto .

In astratto, se vuoi ridurre il numero di argomenti passati alle funzioni e molti di questi argomenti si ripetono, puoi usare l'incapsulamento. Questo può assumere la forma di una struttura dati (elenco, mappa hash, ecc.). Se esiste un'elevata coesione tra i dati e le funzioni, è anche possibile creare una classe in cui le funzioni sono metodi.

In alternativa, se gli argomenti sono compilati su blocchi logici diversi o nel tempo, è possibile utilizzare l'applicazione parziale. Ciò consentirebbe anche il riutilizzo a seconda del tempo in cui i dati sono validi. Ad esempio se alcuni dati sono determinati all'avvio dell'applicazione e raramente i cambiamenti potrei usare un'applicazione parziale e riutilizzare la funzione risultante finché non cambia. Se chiami molte funzioni diverse con molti degli stessi argomenti, puoi utilizzare la compose e l'applicazione parziale per gestire la complessità del codice.

FYI: ci sono sicuramente altri modi per risolvere questo problema che potrebbe funzionare meglio per un tuo specifico esempio. Ad esempio, potresti anche voler usare un Singleton, globali, variabili di classe, ecc. Ci saranno diversi costi e benefici per qualsiasi tecnica di organizzazione del codice. Usa qualsiasi cosa ti dà la più piccola implementazione che sia estensibile, manutenibile e leggibile.