Perché il modello di iniezione delle dipendenze non era incluso nella banda di quattro ? Il GOF ha preceduto un test automatizzato diffuso? L'iniezione di dipendenza è ora considerata un modello principale?
Perché il modello di iniezione delle dipendenze non era incluso nella banda di quattro ? Il GOF ha preceduto un test automatizzato diffuso? L'iniezione di dipendenza è ora considerata un modello principale?
Sono stato redattore della rivista Software Development quando è uscito 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 è stato originariamente pubblicato.
Nel 1994, il C ++ era il linguaggio orientato agli oggetti più comunemente usato, e la maggior parte delle persone che lo programmavano provenivano da uno sfondo C. Uno degli aspetti del "pensare negli oggetti" che le persone semplicemente non avevano è l'idea di centinaia o migliaia di punti di ingresso nel programma. Hai pensato a main() . Se hai lavorato su un progetto di grandi dimensioni, potresti avere un makefile (di solito piuttosto elaborato) per creare un programma basato su moduli. Ma "unit test"? Avvio di un processo, creazione del contesto di memoria necessario, esecuzione e abbattimento, in base a per metodo ? E 'stato molto radicale.
Java ha reso più ovvia la programmazione a punti multipli. Al momento del boom originale di Dot-Com, il collaudo delle unità era una tecnica ben conosciuta, ma in realtà era JUnit (circa 2001) che lo ha fatto prendere fuoco e diventare una pratica universale.
Sebbene Strategia e il concetto generale di programmazione di un'interfaccia facessero parte di GoF e dello zeitgeist di metà anni '90, l'idea di injection arrivò piuttosto tardi al party ( circa '03 -'05?). Onestamente, i miei capelli grigi sono ancora piuttosto dubbi riguardo a questo aspetto di DI ("Scendi dal mio prato, dannatamente file di configurazione!").
L'hanno chiamato Strategia .
La loro strategia sembra avere tutte le caratteristiche dell'integrazione delle dipendenze senza il nome dal suono complesso.
Penso che la dipendenza dall'iniezione 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 precedente sembra essere corretto. Se la banda dovesse raccogliere e segregare modelli nel 2012, sicuramente l'iniezione di dipendenza sarà lì.
La strategia potrebbe emergere nelle discussioni, ma la strategia non parla dell'iniezione di dipendenza. Ma quando si utilizza un modello di strategia in un singolo progetto o dll (tutte le classi e le interfacce rimangono in un progetto), sembra che stiamo facendo un'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, allora dovremo usare le tecniche di iniezione delle dipendenze. Potremmo usare i file di configurazione dell'unità (non è possibile tuttavia alcuna modifica in fase di esecuzione). Ma il modello di strategia non dice come iniettare una dipendenza.
Se esiste un modello simile a quello dell'iniezione delle dipendenze, si tratta di un modello di metodo astratto. Questo modello può 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 in modo indipendente 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 modelli per descrivere la progettazione del software."
Un modello di design non dipende dal suo utilizzo. L'iniezione di dipendenza viene implementata utilizzando il modello di strategia. Se nominassimo ciascun modello in base al caso d'uso, dovremmo rinominare un sacco di modelli.
Il pattern del repository non è un nuovo pattern, è il Pattern Template.
"Nel metodo template di questo modello di progettazione, uno o più passaggi dell'algoritmo possono essere sovrascritti dalle sottoclassi per consentire comportamenti diversi garantendo al tempo stesso che l'algoritmo di overarching sia ancora seguito."
Spesso i pattern sono più pattern combinati e denominati come il pattern MVC.
Il GOF non aveva interfacce nelle classi Pure Abstract usate, e inoltre ha sfruttato la capacità di C ++ di ereditare da più di una classe.
Leggi altre domande sui tag design-patterns