Cambia richiesta di un comportamento implementato in profondità nello stack di chiamate ma è configurato nelle prime chiamate

1

Problema : ho un sistema complesso con molti livelli di astrazioni. Ho bisogno di un comportamento diverso basso nelle astrazioni, ma per essere configurato in alto nell'astrazione.

Soluzione 1 : avere un parametro per definire il comportamento scelto e passare questo parametro nell'astrazione fino al metodo che lo usa.

Soluzione 2 : avere un modulo di configurazione impostato in alto nell'astrazione e il modulo in basso nell'astrazione ha accesso al modulo di configurazione.

Soluzione 3 : modello di progettazione della strategia?

Secondo il libro Codice pulito, la soluzione 1 non funziona perché una funzione non dovrebbe avere i flag di controllo come parametri, il diverso percorso dovrebbe diventare una nuova funzione. In questo caso, duplicare ciò che viene chiamato in questa funzione e in quelle sottostanti.

Il problema con la soluzione 2 è lo scopo della configurazione, se è troppo alto diventa difficile testare il codice perché ho una dipendenza che non posso iniettare, se mi inietto sono tipo nella soluzione 1 Inoltre, seguendo un'architettura esagonale, potrei forzare il mio livello di applicazione a dipendere da moduli esterni, ad esempio se l'utente accede a percorsi di codice diversi a seconda della pagina in cui ha effettuato l'accesso alla funzionalità.

Un amico mi ha consigliato di dare un'occhiata al modello di strategia, ma per quello che ricordo deve passare un riferimento all'implementazione che verrà utilizzata e alla fine è simile all'iniezione della dipendenza.

La mia conclusione

Ritengo che la soluzione 2 sia migliore in quanto posso definire in quale livello dell'astrazione avrò questo modulo di configurazione, ma vorrei sapere se il problema è risolto per un modello di progettazione migliore o una strategia di refactoring.

    
posta Jp_ 14.09.2018 - 18:30
fonte

1 risposta

1

Il passaggio dei parametri di configurazione dai livelli "superiori" ai livelli "inferiori" (invece di lasciare che i livelli inferiori accedano direttamente ai dati di configurazione) va bene. Ma si tratta di livelli , non di funzioni.

Ciò che hai trovato nel libro Clean Code di Uncle Bob sui flag di controllo è puramente inteso per funzioni: ogni funzione fa parte di una classe, di un modulo, di un componente o di un layer e quando la classe, modulo, componente o livello è costruito o inizializzato, quindi è perfettamente ok passare i parametri di configurazione da un'unità di livello superiore a questa unità di livello inferiore, come parte del processo di costruzione o di inizializzazione. Ad esempio, se l'unità è una classe, si può passare un flag di configurazione attraverso il costruttore e memorizzarne il valore all'interno di una variabile membro. AFAIK non ci sono raccomandazioni nel libro Codice pulito contro questo tipo di design.

Le funzioni all'interno di tale livello possono quindi accedere direttamente a questa configurazione specifica del livello, senza ottenere il valore passato come parametro. Oppure il codice di inizializzazione del livello / classe / modulo / componente prende la configurazione e la usa per costruire un determinato oggetto di strategia. Questo è lo scopo del modello strategico: è un modo pulito per implementare il comportamento dipendente dalla configurazione all'interno di un livello.

    
risposta data 14.09.2018 - 21:42
fonte