Principio di inversione di dipendenza: come definire "politica di alto livello" e "dettaglio di basso livello" per le altre persone?

Sto cercando di spiegare il principio di inversione di dipendenza ai miei colleghi (principalmente junior). Come possiamo definire quale sia la "politica di alto livello" e quale sia il "dettaglio di basso livello" in un software? Ad esempio, se il nostro software automatizza il flusso di lavoro di diverse applicazioni aziendali, perché diciamo che l'automazione del flusso di lavoro è la politica di alto livello e che le applicazioni aziendali sono i dettagli?

Nota: questo è stato completamente riscritto dal mio esempio precedente

Pensa alle prese di corrente. In ogni nazione, la politica di alto livello è che le prese di corrente siano sempre le stesse. Non importa da dove provenga l'elettricità (carbone, gas, nucleare), le prese sul muro dovrebbero sempre emettere la stessa quantità di energia, attraverso lo stesso set di connettori.

Ora puoi collegare qualsiasi dispositivo a quella presa, perché tutti hanno un'interfaccia comune, la "spina". La politica di alto livello non deve mai dettare alcuna parte di tali dettagli di implementazione. Basta collegare qualcosa e funziona.

Ora se hai un dispositivo che non desidera l'alimentazione CA - forse funziona su un circuito a 7 V CC - puoi comunque utilizzare questa politica di alto livello, hai solo bisogno di un qualche tipo di adattatore tra l'alimentatore e il dispositivo. E poiché tutti hanno la stessa politica di alto livello, il produttore può integrarla nell'implementazione, senza alcuna modifica della politica di alto livello. La persona che collega l'implementazione alla politica (tu, collegando il tuo laptop) non ha davvero bisogno di capire neanche.

Inoltre, se il produttore desidera vendere lo stesso dispositivo in un altro paese, è sufficiente sviluppare un adattatore diverso. Quindi la stessa implementazione può funzionare con più policy mentre la stessa policy può eseguire più implementazioni.

Questo è un esempio perfetto di inversione di dipendenza.

Ma ecco la parte interessante: torna a quello che ho detto per la prima volta. "Non importa da dove prendi l'elettricità." Anche questo è un dettaglio di implementazione. La politica di alto livello è che tutte le prese di corrente hanno la stessa forma ed emettono lo stesso tipo di alimentazione. I dettagli dell'implementazione di basso livello sono sia la provenienza dell'elettricità sia il suo funzionamento.

In termini di programmazione, ciò significa che la politica di alto livello è l'interfaccia (dove una lingua la supporta. Un'altra forma di DI è la digitazione anatra.) Che fornisce un'API e l'applicazione consuma, ei dettagli dell'implementazione di basso livello sono entrambi applicazione che lo consuma e l'API stessa, nessuna delle quali deve capirsi.

Gli adattatori possono essere utilizzati per adattare la stessa implementazione a politiche diverse.

L'approccio classico nel riutilizzo del software è quello di costruire componenti che non dipendono da nient'altro (che è ciò che li rende di basso livello) e quindi costruire componenti di livello superiore che dipendono da componenti di livello inferiore. "alto livello" e "basso livello" sono determinati in modo specifico dalla direzione della dipendenza, che non è inerente alla funzione del componente, ma spesso solo una decisione architettonica.

Pertanto, quando le singole applicazioni aziendali vengono create senza alcuna dipendenza dall'automazione del flusso di lavoro, ma il controller del flusso di lavoro ha dipendenze dirette con l'applicazione aziendale, allora dovrebbe essere chiaro che l'automazione del flusso di lavoro è una "politica di alto livello" e l'applicazione aziendale è un componente "basso livello". Si noti che questa struttura non è obbligatoria: se il componente di automazione del flusso di lavoro è un framework generale, che non è neanche accoppiato alle applicazioni aziendali specifiche, ma può essere configurato per servire applicazioni diverse, allora hai già iniziato ad applicare il DIP. In questa situazione, la separazione "alto livello" / "basso livello" potrebbe non avere più senso tra queste due cose.

Pertanto, il nome "inversione di dipendenza" è in qualche modo fuorviante, poiché le dipendenze non vengono "inverse", ma completamente rimosse (o per essere più precisi: cambiate da essere dipendenze di compilazione in dipendenze di runtime).

Uso una semplice immagine per spiegare DIP. La visione classica dello sviluppo del software è come un processo di costruzione con ogni strato sopra gli strati inferiori che lo supportano. L'uso del principio di inversione di dipendenza è più simile alla costruzione di un cellulare.

Piuttosto che i livelli superiori che si trovano sui livelli inferiori, i livelli superiori nell'interfaccia mobile con i livelli inferiori tramite la stringa che li collega. In un certo senso, i livelli inferiori dipendono da quell'interfaccia per il supporto (senza la stringa che cadono). Questo è DIP in breve.