Pattern per passare il contesto attraverso una catena di metodi

Questa è una decisione progettuale che sembra emergere molto: come passare il contesto attraverso un metodo che non ne ha bisogno a un metodo che lo fa. C'è una risposta giusta o dipende dal contesto.

Codice di esempio che richiede una soluzione

// needs the dependency
function baz(session) {
  session('baz');
}

// doesn't care about the dependency
function bar() {
  baz();
}

// needs the dependency
function foo(session) {
   session('foo')
   bar();
}

// creates the dependency
function start() {
  let session = new Session();
  foo(session);
}

Possibili soluzioni

• ThreadLocal
• globale
• oggetto contestuale
• passare la dipendenza
• curry baz e passalo al bar con la dipendenza impostata come primo arg
• iniezione di dipendenza

Esempi di dove viene

Elaborazione richiesta HTTP

Vengono spesso utilizzati oggetti di contesto sotto forma di attributi di richiesta: consultare expressjs, servlet Java o .net's owin.

Registrazione

Per la registrazione di Java, le persone usano spesso globi / singleton. Vedi i tipici schemi di log4j / commons logging / java logging.

Le transazioni

I locali dei thread vengono spesso utilizzati per mantenere una transazione o una sessione associata a una catena di chiamate al metodo per evitare di doverle passare come parametri a tutti i metodi che non ne hanno bisogno.

L'unica risposta corretta è che dipende dai modi di dire del tuo paradigma di programmazione. Se stai usando OO, è quasi certamente errato passare una dipendenza da metodo a metodo a metodo. È un odore di codice in OO. In realtà, questo è uno dei problemi che OO risolve: un oggetto corregge un contesto. Quindi, in OO, un approccio corretto (ci sono sempre altri modi) è quello di fornire la dipendenza tramite il contraente o la proprietà. Un commentatore menziona "Iniezione di dipendenza" e questo è perfettamente legittimo, ma non è strettamente necessario. Fornisci la dipendenza in modo che sia disponibile come membro a fooe baz.

Lei parla di curry, quindi suppongo che la programmazione funzionale non sia fuori discussione. In tal caso, un equivalente filosofico del contesto dell'oggetto è la chiusura. Qualsiasi approccio che, ancora una volta, corregge la dipendenza in modo che sia disponibile per le persone a carico funziona bene. Currying è uno di questi approcci (e ti fa sembrare intelligente). Ricorda solo che ci sono altri modi per chiudere una dipendenza. Alcuni sono eleganti e altri terribili.

Non dimenticare la programmazione orientata agli aspetti . Sembra essere caduto in disgrazia negli ultimi anni, ma il suo obiettivo principale è risolvere esattamente il problema che descrivi. In effetti, il classico esempio di Aspect è la registrazione. In AOP, la dipendenza viene aggiunta automaticamente dopo la scrittura di altro codice. La gente di AOP la chiama " tessitura ". Gli aspetti comuni sono inseriti nel codice nei punti appropriati. Questo rende il tuo codice più facile da pensare ed è dannatamente bello, ma aggiunge anche un nuovo onere di prova. Avrai bisogno di un modo per determinare se i tuoi artefatti finali sono validi. AOP ha risposte anche per questo, quindi non sentirti intimidito.

Se bardipende da baz, che a sua volta richiede dependency, allora barrichiede dependencyanche troppo per un corretto utilizzo baz. Pertanto, gli approcci corretti sarebbero o passare la dipendenza come parametro a bar, o curry baze passarla a bar.

Il primo approccio è più semplice da implementare e leggere, ma crea un accoppiamento tra bare baz. Il secondo approccio rimuove tale accoppiamento, ma potrebbe risultare in un codice meno chiaro. L'approccio migliore dipenderà quindi probabilmente dalla complessità e dal comportamento di entrambe le funzioni. Ad esempio, se bazo dependencyhanno effetti collaterali, la facilità di test sarà probabilmente un driver di grandi dimensioni in cui viene scelta la soluzione.

Suggerirei che tutte le altre opzioni che proponete siano di natura "confusa" e che possano causare problemi sia con i test che con problemi difficili da rintracciare.

Filosoficamente parlando

Sono d'accordo con la preoccupazione di David Arno .

Sto leggendo l'OP come alla ricerca di soluzioni di implementazione. Tuttavia, la risposta è cambiare il design . "Patterns"? Il design di OO è, si potrebbe dire, tutto basato sul contesto. È un vasto foglio di carta bianco pieno di possibilità.

Trattare con il codice esistente è un contesto diverso, bene.

Sto lavorando allo stesso problema proprio adesso. Bene, sto riparando le centinaia di righe di codice copy-n-paste che sono state fatte proprio per poter iniettare un valore.

Modularizza il codice

Ho gettato via 600 righe di codice duplicato, quindi ho eseguito il refactoring, quindi invece di "A chiama B chiama C chiama D ..." Ho "Chiama A, ritorna, Chiama B, ritorna, Chiama C ...". Ora dobbiamo solo iniettare il valore in uno di quei metodi, diciamo il metodo E.

Aggiungi un parametro predefinito al costruttore. I chiamanti esistenti non cambiano - "opzionale" è la parola chiave qui. Se non viene passato un argomento, viene utilizzato il valore predefinito. Quindi cambia solo 1 riga per passare la variabile nella struttura modulare refactored; e una piccola modifica nel metodo E per usarlo.

chiusure

Un thread di programmatori - "Perché un programma dovrebbe usare una chiusura?"

In sostanza, si stanno iniettando valori in un metodo che restituisce un metodo personalizzato con i valori. Tale metodo personalizzato viene successivamente eseguito.

Questa tecnica ti consentirebbe di modificare un metodo esistente senza cambiarne la firma.