Esiste un nome per il modello (anti) di passaggio dei parametri che verrà utilizzato solo per diversi livelli in profondità nella catena di chiamate?

Stavo cercando di trovare alternative all'uso della variabile globale in alcuni codici legacy. Ma questa domanda non riguarda le alternative tecniche, sono principalmente preoccupato per la terminologia .

La soluzione ovvia è passare un parametro nella funzione invece di usare un globale. In questa base di codice legacy ciò significherebbe che devo cambiare tutte le funzioni nella lunga catena di chiamate tra il punto in cui verrà eventualmente utilizzato il valore e la funzione che riceve per prima il parametro.

higherlevel(newParam)->level1(newParam)->level2(newParam)->level3(newParam)

dove in newParamprecedenza era una variabile globale nel mio esempio, ma avrebbe potuto essere invece un valore precedentemente codificato. Il punto è che ora il valore di newParam è ottenuto higherlevel()e deve "viaggiare" fino in fondo level3().

Mi chiedevo se ci fosse un nome per questo tipo di situazione / modello in cui è necessario aggiungere un parametro a molte funzioni che "passano" il valore non modificato.

Spero che l'uso della terminologia appropriata mi permetta di trovare più risorse sulle soluzioni per la riprogettazione e descrivere questa situazione ai colleghi.

I dati stessi si chiamano "dati del vagabondo" . È un "odore di codice", che indica che un pezzo di codice sta comunicando con un altro pezzo di codice a distanza, attraverso intermediari.

• Aumenta la rigidità del codice, specialmente nella catena di chiamate. Sei molto più limitato nel modo in cui rifletti qualsiasi metodo nella catena di chiamate.
• Distribuisce conoscenze su dati / metodi / architettura in luoghi a cui non importa minimamente. Se è necessario dichiarare i dati che stanno attraversando e la dichiarazione richiede una nuova importazione, è stato inquinato lo spazio dei nomi.

Rifattorizzare per rimuovere le variabili globali è difficile e i dati del vagabondo sono un metodo per farlo, e spesso il modo più economico. Ha i suoi costi.

Non penso che questo, di per sé, sia un anti-schema. Penso che il problema sia che stai pensando alle funzioni come a una catena quando in realtà dovresti pensare a ognuna come una scatola nera indipendente ( NOTA : i metodi ricorsivi sono una notevole eccezione a questo consiglio.)

Ad esempio, supponiamo che sia necessario calcolare il numero di giorni tra due date del calendario in modo da creare una funzione:

int daysBetween(Day a, Day b)

Per fare ciò, creo una nuova funzione:

int daysSinceEpoch(Day day)

Quindi la mia prima funzione diventa semplicemente:

int daysBetween(Day a, Day b)
{
    return daysSinceEpoch(b) - daysSinceEpoch(a);
}

Non c'è niente di anti-pattern in questo. I parametri del metodo daysB Between vengono passati a un altro metodo e non vengono mai citati altrimenti nel metodo, ma sono ancora necessari affinché quel metodo faccia quello che deve fare.

Quello che consiglierei è guardare ogni funzione e iniziare con un paio di domande:

• Questa funzione ha un obiettivo chiaro e mirato o è un metodo "fai alcune cose"? Di solito il nome della funzione aiuta qui e se c'è qualcosa che non è descritto dal nome, è una bandiera rossa.
• Ci sono troppi parametri? A volte un metodo può legittimamente richiedere un sacco di input ma avere così tanti parametri rende oneroso da usare o capire.

Se stai osservando un miscuglio di codice senza un singolo scopo raggruppato in un metodo, dovresti iniziare svelandolo. Questo può essere noioso. Inizia con le cose più semplici da estrarre e passare a un metodo separato e ripetere fino a quando non hai qualcosa di coerente.

Se hai solo troppi parametri, considera il refactoring da metodo a oggetto .

BobDalgleish ha già notato che questo modello (anti-) è chiamato " dati del vagabondo ".

Nella mia esperienza, la causa più comune di eccessivi dati sul vagabondo è avere un mucchio di variabili di stato collegate che dovrebbero davvero essere incapsulate in un oggetto o in una struttura di dati. A volte, potrebbe anche essere necessario nidificare un gruppo di oggetti per organizzare correttamente i dati.

Per un semplice esempio, si consideri un gioco che ha un personaggio personalizzabile, con immobili come playerName, playerEyeColore così via. Naturalmente, il giocatore ha anche una posizione fisica sulla mappa del gioco e varie altre proprietà come, diciamo, il livello di salute attuale e massimo e così via.

In una prima iterazione di un gioco del genere, potrebbe essere una scelta perfettamente ragionevole trasformare tutte queste proprietà in variabili globali - dopotutto, c'è un solo giocatore e quasi tutto nel gioco coinvolge in qualche modo il giocatore. Quindi il tuo stato globale potrebbe contenere variabili come:

playerName = "Bob"
playerEyeColor = GREEN
playerXPosition = -8
playerYPosition = 136
playerHealth = 100
playerMaxHealth = 100

Ma ad un certo punto, potresti scoprire che devi cambiare questo design, forse perché vuoi aggiungere una modalità multiplayer al gioco. Come primo tentativo, potresti provare a rendere tutte quelle variabili locali e passandole a funzioni che ne hanno bisogno. Tuttavia, potresti scoprire che un'azione particolare nel tuo gioco potrebbe comportare una catena di chiamate di funzioni come, ad esempio:

mainGameLoop()
 -> processInputEvent()
     -> doPlayerAction()
         -> movePlayer()
             -> checkCollision()
                 -> interactWithNPC()
                     -> interactWithShopkeeper()

... e la interactWithShopkeeper()funzione ha il negoziante che indirizza il giocatore per nome, quindi ora devi improvvisamente passare playerNamei dati del vagabondo attraverso tutte quelle funzioni. E, naturalmente, se il negoziante ritiene che i giocatori con gli occhi azzurri siano ingenui e addebitino prezzi più alti per loro, allora dovrai passare playerEyeColorattraverso l'intera catena di funzioni e così via.

La soluzione corretta , in questo caso, è ovviamente quella di definire un oggetto giocatore che incapsuli il nome, il colore degli occhi, la posizione, la salute e qualsiasi altra proprietà del personaggio del giocatore. In questo modo, devi solo passare quel singolo oggetto a tutte le funzioni che in qualche modo coinvolgono il giocatore.

Inoltre, molte delle funzioni sopra potrebbero essere naturalmente trasformate in metodi dell'oggetto del giocatore, il che darebbe loro automaticamente l'accesso alle proprietà del giocatore. In un certo senso, questo è solo zucchero sintattico, dal momento che la chiamata di un metodo su un oggetto passa effettivamente l'istanza dell'oggetto come parametro nascosto al metodo, ma rende il codice più chiaro e naturale se usato correttamente.

Certo, un gioco tipico avrebbe uno stato molto più "globale" di un semplice giocatore; per esempio, avresti quasi sicuramente una sorta di mappa su cui si svolge il gioco, e un elenco di personaggi non giocanti che si muovono sulla mappa, e forse oggetti posizionati su di essa, e così via. Potresti anche passare tutti quelli come oggetti vagabondi, ma ciò ingombrerebbe nuovamente gli argomenti del tuo metodo.

Invece, la soluzione consiste nel fare in modo che gli oggetti memorizzino i riferimenti a qualsiasi altro oggetto con cui hanno relazioni permanenti o temporanee. Quindi, per esempio, l'oggetto giocatore (e probabilmente anche qualsiasi oggetto NPC) probabilmente dovrebbe memorizzare un riferimento all'oggetto "mondo di gioco", che avrebbe un riferimento al livello / mappa corrente, in modo che un metodo come player.moveTo(x, y)non abbia bisogno di ricevere esplicitamente la mappa come parametro.

Allo stesso modo, se il nostro personaggio del giocatore avesse, diciamo, un cane da compagnia che li seguiva in giro, raggrupperemmo naturalmente tutte le variabili di stato che descrivono il cane in un singolo oggetto e darebbe al giocatore un riferimento al cane (in modo che il giocatore possa , diciamo, chiama il cane per nome) e viceversa (in modo che il cane sappia dove si trova il giocatore). E, naturalmente, vorremmo probabilmente rendere il giocatore e il cane oggetti entrambe le sottoclassi di un oggetto "attore" più generico, in modo che possiamo riutilizzare lo stesso codice per, diciamo, spostandoci entrambi sulla mappa.

Ps. Anche se ho usato un gioco come esempio, ci sono altri tipi di programmi in cui si presentano anche questi problemi. Nella mia esperienza, tuttavia, il problema di fondo tende ad essere sempre lo stesso: hai un sacco di variabili separate (sia locali che globali) che vogliono davvero essere raggruppate in uno o più oggetti interconnessi. Indipendentemente dal fatto che i "dati vaganti" che si intromettono nelle tue funzioni consistano in impostazioni "globali" delle opzioni o query nella cache memorizzate o vettori di stato in una simulazione numerica, la soluzione è invariabilmente identificare il contesto naturale a cui appartengono i dati e trasformarlo in un oggetto (o qualunque sia l'equivalente più vicino nella lingua scelta).

Non sono a conoscenza di un nome specifico per questo, ma credo che valga la pena menzionare che il problema che descrivi è solo il problema di trovare il miglior compromesso per l'ambito di tale parametro:

• come variabile globale, l'ambito è troppo grande quando il programma raggiunge una certa dimensione

• come parametro puramente locale, l'ambito potrebbe essere troppo piccolo, quando porta a molti elenchi di parametri ripetitivi nelle catene di chiamate

• così come un compromesso, puoi spesso rendere tale parametro una variabile membro in una o più classi, ed è quello che definirei un corretto design di classe .

Credo che lo schema che stai descrivendo sia esattamente l' iniezione di dipendenza . Numerosi commentatori hanno affermato che si tratta di un modello , non di un modello , e io tenderei ad essere d'accordo.

Concordo anche con la risposta di @ JimmyJames, in cui afferma che è buona prassi di programmazione trattare ogni funzione come una scatola nera che accetta tutti i suoi input come parametri espliciti. Cioè, se stai scrivendo una funzione che produce un panino con burro di arachidi e gelatina, potresti scriverlo come

Sandwich make_sandwich() {
    PeanutButter pb = get_peanut_butter();
    Jelly j = get_jelly();
    return pb + j;
}
extern PhysicalRefrigerator g_refrigerator;
PeanutButter get_peanut_butter() {
    return g_refrigerator.get("peanut butter");
}
Jelly get_jelly() {
    return g_refrigerator.get("jelly");
}

ma sarebbe meglio applicare l'iniezione di dipendenza e scriverla così:

Sandwich make_sandwich(Refrigerator& r) {
    PeanutButter pb = get_peanut_butter(r);
    Jelly j = get_jelly(r);
    return pb + j;
}
PeanutButter get_peanut_butter(Refrigerator& r) {
    return r.get("peanut butter");
}
Jelly get_jelly(Refrigerator& r) {
    return r.get("jelly");
}

Ora hai una funzione che documenta chiaramente tutte le sue dipendenze nella sua firma della funzione, che è ottima per la leggibilità. Dopo tutto, è vero che per poter make_sandwichaccedere a un Refrigerator; quindi la vecchia firma della funzione era sostanzialmente disingenua non prendendo il frigorifero come parte dei suoi input.

Come bonus, se esegui la tua gerarchia di classi nel modo giusto, evita il taglio e così via, puoi persino testare l'unità della make_sandwichfunzione passando un MockRefrigerator! (Potrebbe essere necessario testare l'unità in questo modo perché l'ambiente di test unità potrebbe non avere accesso a nessun messaggio di posta PhysicalRefrigeratorelettronica.)

Capisco che non tutti gli usi dell'iniezione di dipendenza richiedono di inserire un parametro con lo stesso nome su molti livelli nello stack di chiamate, quindi non sto rispondendo esattamente alla domanda che hai posto ... ma se stai cercando ulteriori letture su questo argomento, "Iniezione delle dipendenze" è sicuramente una parola chiave pertinente per te.

Questa è praticamente la definizione da manuale di accoppiamento , un modulo che ha una dipendenza che influenza profondamente un altro e che crea un effetto a catena quando viene cambiato. Gli altri commenti e risposte hanno ragione sul fatto che si tratta di un miglioramento rispetto al globale, poiché l'accoppiamento è ora più esplicito e più facile da vedere per il programmatore, anziché sovversivo. Ciò non significa che non dovrebbe essere riparato. Dovresti essere in grado di rifattorizzare per rimuovere o ridurre l'accoppiamento, anche se se è stato lì per un po 'può essere doloroso.

Sebbene questa risposta non risponda direttamente alla tua domanda, penso che sarei negligente lasciarla passare senza menzionare come migliorarla (poiché, come dici, potrebbe essere un anti-schema). Spero che tu e altri lettori possiate trarre valore da questo commento aggiuntivo su come evitare i "dati vagabondi" (come Bob Dalgleish lo ha così utilmente chiamato per noi).

Concordo con le risposte che suggeriscono di fare qualcosa di più OO per evitare questo problema. Tuttavia, un altro modo per aiutare a ridurre profondamente questo passaggio di argomenti senza passare semplicemente a " passare una classe in cui passavi molti argomenti! " È il refactoring in modo che alcuni passaggi del processo avvengano a livello superiore anziché inferiore uno. Ad esempio, eccone alcuni prima del codice:

public void PerformReporting(StuffRepository repo, string desiredName) {
   var stuffs = repo.GetStuff(DateTime.Now());
   FilterAndReportStuff(stuffs, desiredName);
}

public void FilterAndReportStuff(IEnumerable<Stuff> stuffs, string desiredName) {
   var filter = CreateStuffFilter(FilterTypes.Name, desiredName);
   ReportStuff(stuffs.Filter(filter));
}

public void ReportStuff(IEnumerable<Stuff> stuffs) {
   stuffs.Report();
}

Si noti che questo peggiora ancora di più le cose da fare ReportStuff. Potrebbe essere necessario passare l'istanza del reporter che si desidera utilizzare. E tutti i tipi di dipendenze che devono essere consegnate, funzionano in funzione annidata.

Il mio suggerimento è di portare tutto ciò a un livello superiore, in cui la conoscenza dei passaggi richiede la vita in un singolo metodo invece di essere diffusa in una catena di chiamate di metodo. Naturalmente sarebbe più complicato nel codice reale, ma questo ti dà un'idea:

public void PerformReporting(StuffRepository repo, string desiredName) {
   var stuffs = repo.GetStuff(DateTime.Now());
   var filter = CreateStuffFilter(FilterTypes.Name, desiredName);
   var filteredStuffs = stuffs.Filter(filter)
   filteredStuffs.Report();
}

Nota che la grande differenza qui è che non devi passare le dipendenze attraverso una lunga catena. Anche se ti appiattisci non solo a un livello, ma a pochi livelli di profondità, se anche questi livelli raggiungono un certo "appiattimento" in modo che il processo venga visto come una serie di passaggi a quel livello, avrai apportato un miglioramento.

Mentre questo è ancora procedurale e nulla è stato ancora trasformato in un oggetto, è un buon passo per decidere quale tipo di incapsulamento è possibile ottenere trasformando qualcosa in una classe. Il metodo profondamente incatenato nello scenario precedente nasconde i dettagli di ciò che sta realmente accadendo e può rendere il codice molto difficile da capire. Mentre puoi esagerare e finire per far conoscere il codice di livello superiore a cose che non dovrebbero, o fare un metodo che fa troppe cose violando così il principio della responsabilità singola, in generale ho scoperto che l'appiattimento delle cose aiuta un po ' nella chiarezza e nel fare cambiamenti incrementali verso un codice migliore.

Nota che mentre stai facendo tutto questo, dovresti considerare la testabilità. Le chiamate del metodo concatenato in realtà rendono più difficile il test unitario perché non si dispone di un buon punto di ingresso e punto di uscita nell'assieme per la sezione che si desidera verificare. Nota che con questo appiattimento, poiché i tuoi metodi non richiedono più così tante dipendenze, sono più facili da testare, non richiedono altrettante beffe!

Di recente ho provato ad aggiungere test unitari a una classe (che non avevo scritto) che richiedeva qualcosa come 17 dipendenze, tutte da deridere! Non ho ancora capito tutto, ma ho diviso la classe in tre classi, ciascuna con uno dei nomi separati di cui si occupava, e ho ridotto l'elenco delle dipendenze a 12 per il peggiore e circa 8 per il il migliore.

La testabilità ti costringerà a scrivere codice migliore. Dovresti scrivere unit test perché scoprirai che ti fa pensare al tuo codice in modo diverso e scriverai un codice migliore sin dall'inizio, indipendentemente da quanti bug potresti aver avuto prima di scrivere i test unitari.

Non stai letteralmente violando la Legge di Demetra, ma il tuo problema è simile a quello in qualche modo. Poiché il punto della tua domanda è trovare risorse, ti suggerisco di leggere su Legge di Demetra e vedere quanto di questi consigli si applica alla tua situazione.

Ci sono casi in cui il migliore (in termini di efficienza, manutenibilità e facilità di implementazione) di avere determinate variabili come globali piuttosto che il sovraccarico di passare sempre tutto intorno (diciamo che hai circa 15 variabili che devono persistere). Quindi ha senso trovare un linguaggio di programmazione che supporti meglio l'ambito (come le variabili statiche private di C ++) per alleviare il potenziale disordine (dello spazio dei nomi e manomettere le cose). Naturalmente questa è solo conoscenza comune.

Tuttavia, l'approccio indicato dall'OP è molto utile se si sta eseguendo la programmazione funzionale.

Non esiste affatto un anti-pattern, perché il chiamante non è a conoscenza di tutti questi livelli sottostanti e non gli importa.

Qualcuno sta chiamando higherLevel (params) e si aspetta che higherLevel faccia il suo lavoro. Quello che un livello superiore fa con params non è affare dei chiamanti. higherLevel gestisce il problema nel miglior modo possibile, in questo caso passando i parametri a livello 1 (parametri). Va assolutamente bene.

Vedi una catena di chiamate, ma non esiste una catena di chiamate. C'è una funzione in alto che fa il suo lavoro nel miglior modo possibile. E ci sono altre funzioni. Ogni funzione può essere sostituita in qualsiasi momento.