Perché il modello di iniezione di dipendenza non era incluso nella banda di quattro?

Perché il modello di iniezione di dipendenza non era incluso nella banda di quattro ? GOF ha pre-datato i test automatici diffusi? L'iniezione di dipendenza è ora considerata un modello di base?

Ero redattore della rivista Software Development quando uscì il libro Gang of Four e posso dire con totale fiducia che il test unitario non era una pratica diffusa nel 1994, quando Design Patterns fu originariamente pubblicato.

Nel 1994, C ++ era il linguaggio orientato agli oggetti più comunemente usato e la maggior parte delle persone che lo programmavano provenivano da un background C. Una delle cose del "pensare negli oggetti" che le persone semplicemente non avevano è l'idea di centinaia o migliaia di punti di accesso al tuo programma. Hai pensato al main(). Se hai lavorato su un grande progetto, potresti avere un (solitamente abbastanza elaborato) makefile per creare un programma basato su moduli. Ma "unit test"? Avvio di un processo, creazione del contesto di memoria necessario, esecuzione e riduzione in base al metodo ? È stato molto radicale.

Java ha reso più ovvia la programmazione con più punti di accesso. All'epoca del boom originale della Dot-Com, i test unitari erano una tecnica ben nota, ma era proprio la JUnit (circa 2001?) Che le fece prendere fuoco e diventare una pratica universale.

Sebbene la strategia e il concetto generale di programmazione di un'interfaccia facessero parte del GoF e dello zeitgeist della metà degli anni '90, l'idea dell'iniezione è arrivata abbastanza tardi al partito (circa '03 -'05?). Onestamente, i miei capelli grigi sono ancora abbastanza dubbiosi su quell'aspetto di DI ("Esci dal mio prato, dannatamente file di configurazione!").

Lo chiamavano Strategia .

La loro strategia sembra avere tutte le caratteristiche dell'iniezione di dipendenza senza il nome dal suono complesso.

Penso che l'iniezione delle dipendenze sia più rilevante quando si separa l'implementazione nei livelli. Un'altra area in cui pensiamo all'iniezione di dipendenza è il test unitario. E il tuo suggerimento prima della data sembra essere corretto. Se la banda dovesse raccogliere e separare i modelli nel 2012, sicuramente ci sarà l'iniezione di dipendenza.

La strategia potrebbe emergere nelle discussioni, ma la strategia non parla dell'iniezione di dipendenza. Ma quando si utilizza il modello di strategia in un singolo progetto o DLL (tutte le classi e le interfacce rimangono in un unico progetto) sembra che stiamo facendo l'iniezione di dipendenza. In realtà non lo siamo.

Ora, se le classi e le interfacce menzionate nel modello di strategia sono separate in diversi progetti o livelli, dovremo usare tecniche di iniezione di dipendenza. Potremmo usare i file di configurazione di unity (tuttavia non è possibile modificare il runtime). Ma il modello di strategia non dice come iniettare una dipendenza.

Se esiste un modello simile a quello dell'iniezione di dipendenza, si tratta del modello Metodo di fabbrica astratto. Questo modello potrebbe essere utilizzato all'interno di un modello di strategia per iniettare dipendenza.

la strategia di risposta è corretta al 100%. Ho votato ma posso commentare.

"La strategia consente all'algoritmo di variare indipendentemente dai client che lo utilizzano. [1] La strategia è uno dei modelli inclusi nell'influente libro Design Patterns di Gamma et al. Che ha reso popolare il concetto di utilizzare i modelli per descrivere la progettazione del software."

Un modello di progettazione non dipende dal suo utilizzo. L'iniezione delle dipendenze viene implementata utilizzando il modello di strategia. Se chiamassimo ogni modello in base al caso d'uso dovremmo rinominare molti schemi.

Il modello di repository non è un nuovo modello, è il modello di modello.

"Nel metodo modello di questo modello di progettazione, una o più fasi dell'algoritmo possono essere sovrascritte da sottoclassi per consentire comportamenti diversi garantendo al contempo che l'algoritmo generale sia ancora seguito."

Spesso i motivi sono più motivi combinati e denominati come il modello MVC.

Il GOF non aveva interfacce con le classi Pure Abstract utilizzate e sfruttò anche la capacità del C ++ di ereditare da più di una classe.