Iniezione delle dipendenze vs Livelli di miscelazione dell'astrazione

Iniziamo definendo cos'è una astrazione . In Agile Principles, Patterns and Practices , Robert C. Martin definisce un'astrazione come questa:

Abstraction is the elimination of the irrelevant and the amplification of the essential

Ciò che è essenziale e ciò che è irrilevante, cambia con la prospettiva del cliente. Dal punto di vista del Root di composizione , le astrazioni rilevanti sono tipi (classi , primitive, ecc.) e il grafico (s) composto da oggetti.

Lo scopo della composizione della radice è costruire un grafico di oggetto valido . In questa prospettiva, tutti i tipi hanno lo stesso livello di astrazione. Sono solo tipi che vengono composti insieme; la Composizione Root non richiama nessuno dei membri dell'oggetto, quindi è irrilevante se l'oggetto proviene da un pacchetto UI, un pacchetto Accesso dati, un pacchetto Modello dominio, ecc. L'astrazione è Composizione.

La mia interpretazione è che i livelli di astrazione non si riferiscono agli oggetti che una funzione può vedere; si riferisce a ciò che in realtà fa . Non è inconcepibile che una funzione debba ricevere e passare lungo un oggetto da un livello molto più basso di astrazione nel processo di delega di compiti al livello immediatamente sottostante. Ma non dovrebbe operare direttamente su tale oggetto.

Se stai incollando cose insieme in main , allora questo è un livello di astrazione. Non ritengo che ci sia alcuna violazione di astrazione qui, perché main non sa nulla di questi oggetti eccetto che uno ha bisogno dell'altro. Se devi fare qualcosa di più complicato per unire le cose insieme, come cercare qualcosa in un file di configurazione per sapere cosa incollare insieme, questo è un livello diverso che dovrebbe essere spostato da qualche altra parte.

Se dovessimo generalizzare la regola un po 'e renderla meno legalistica, potrebbe essere qualcosa del genere:

Limit what each module/class/function/etc knows about the rest of the system.

Quindi hai due tipi di codice:

1. Codice che incolla i nostri strati di astrazione insieme (App)
2. La carne del software che risolve effettivamente un problema (Libro, Database)

Il codice della colla esiste solo in modo che il codice della carne possa fare il suo lavoro. Indipendentemente dal tipo di codice che stai scrivendo, non vuoi che le tue funzioni o moduli conoscano troppo le altre aree del tuo software. Questo è per ragioni di manutenibilità; più pezzi di codice vengono toccati da un modulo, più è probabile che dovrai modificare il codice in tutte quelle aree. Yuck.

Ora, quando scrivi il codice "colla", dovrai ovviamente occuparti di moduli che sono ampiamente diffusi nel tuo software. Ma in realtà non utilizzi usando quei moduli. Il codice della colla è in realtà piuttosto stupido. Si tratta di chiamare alcuni costruttori e per lo più solo mescolare riferimenti a oggetti. Se la tua applicazione diventa abbastanza grande, il tuo codice collettivo diventerà piuttosto grande e complesso, ma questo è ciò che il schema di fabbrica è per .

Quindi, ai miei occhi, è corretto attraversare più livelli di astrazione nel codice della colla, a patto che il codice della colla rimanga non informato su come questi livelli stanno effettivamente lavorando insieme.

Nota a margine:

Dovresti esaminare l'inversione dei contenitori di controllo . Sono ottimi piccoli strumenti che consentono di veramente ridurre al minimo la quantità di codice di colla che si deve scrivere, aumentando potenzialmente la manutenibilità.