Quali sono le differenze tra il modello del ponte e l'iniezione delle dipendenze?Schema del ponte contro l'immissione delle dipendenze
Per entrambi i modelli abbiamo una classe astratta con implementazione di un'altra astrazione. Di seguito è riportato il diagramma UML di Bridge Pattern.
per quanto ne so Dependency Injection è non è un modello di progettazione ma una linea guida disegno definito nel SOLID principles.
Così bridge patternutilizza iniezione di dipendenza in essa per ottenere il comportamento polimorfico richiesto se l'DrawingAPI sta iniettando nel costruttore per disaccoppiare l'Shape dall'attuazione concreta API.
Snippet dall'esempio di Bridge Pattern of Wikipedia
protected Shape(DrawingAPI drawingAPI){
this.drawingAPI = drawingAPI;
}
Ponte Pattern - un modello di progettazione
Dependency Injection - design linee guida o principio
Concordo su ciò che hai detto, ma quando ho letto la definizione da Wiki, è stato detto che "l'iniezione di dipendenza è un modello di progettazione software che implementa l'inversione del controllo per le librerie software" quindi pensi che il termine "modello di progettazione" sia sbagliato o sarebbe corretto in una sorta di vista? – fmchan
@fmchan L'iniezione di dipendenza IMHO è un principio piuttosto che un modello di progettazione. Costituisce il nucleo di molti modelli di progettazione GoF ed è uno dei principi fondamentali di SOLID. –
Si può fare Dependency Injection attraverso diversi meccanismi . Il meccanismo di Bridge è solo uno di questi. L'implementazione dell'interfaccia semplice è un'altra. Intrecci di classe e altri trucchi dinamici ancora un altro.
Dipendenza L'iniezione è una tecnica di sviluppo/progettazione, ma non un modello poiché può essere implementata in diversi modi.
Pensandoci un po 'di più su questo, potresti considerare Dependency Injection un pattern di architettura software (ma non ancora di progettazione), nel senso che è un modo comune di affrontare una serie di problemi di architettura (testabilità, configurabilità, modularità , eccetera).
In altre parole, la dipendenza dall'iniezione potrebbe essere considerata un modello, ma a un livello diverso: architettura, non design.
Il modello di ponte utilizza Dependency Inversion per far funzionare il ponte, ovvero l'interfaccia/classe di base di astrazione dipende dall'interfaccia di Implementor.
Iniezione delle dipendenze è l'implementazione più utilizzata del principio di inversione delle dipendenze.
Molti modelli di progettazione hanno diagrammi UML simili.
Il modello del ponte è completamente diverso dall'iniezione delle dipendenze.
Dependency Injection - Un modo per inserire facilmente (e scambiare) le dipendenze nel codice in fase di runtime o in fase di compilazione.
Bridge Pattern - Un modo per avere un'interfaccia aggiuntiva tra sistemi diversi. The Bridge è lo strato di comunicazione tra il tuo codice e l'altro sistema.Ad esempio, le due implementazioni Bridge Pattern più utilizzate in Java sono JDBC (che comunica con un database tramite un Driver Bridge) e Swing (che utilizza un bridge per comunicare con l'interfaccia utente del sistema operativo). Ciò consente all'altro sistema di essere scambiato o modificato senza alterare o modificare il livello di comunicazione nel sistema.
EDIT: dimenticato di menzionare che un ponte consente anche a entrambi i lati del ponte di evolvere e cambiare indipendentemente senza influenzare l'altro. Questo perché il Ponte isola entrambi i lati l'uno dall'altro.
È corretto affermare che il pattern del bridge utilizza DI per l'istanziazione Implementor? – Warlock
@Warlock si lo direi. DI è un concetto e non un modello di design in sé. Non c'è niente come modello in esso. DI viene utilizzato da secoli anche prima della pubblicazione del libro GoF. Quindi direi che è una linea guida per scrivere codice liberamente accoppiato rispetto a un modello di design. –
@Warlock è possibile utilizzare DI per entrambi gli aspetti dell'istanza di implementazione del bridge, ma non è necessario. – dkatzel
Non sono d'accordo con coloro che sostengono che DI non è un modello di progettazione. Pochi affermerebbero che MVC non è un modello di progettazione e ha anche più modelli di implementazione. –