Ponte vs. adattatore Design Pattern

Question

sono stato interrogato da un collega circa il modello di progettazione della mia realizzazione di un servizio di Windows WCF in un'applicazione client ASP.net e davvero non riuscivo a capire se si tratta di Ponte o adattatore !

Ecco l'attuazione:

• ho ottenuto il contratto di servizio
• Definito una nuova interfaccia simile al mio contratto WCF Data
• ho creato un client WCF e avvolto all'interno della nuova interfaccia
• Mappate le nuove operazioni dell'interfaccia al client WCF originale (eseguo qui la registrazione/gestione degli errori)

L'ho sempre pensato come un'implementazione del modello Adattatore, ma in realtà non riesco a capire perché non lo è Bridge!

Ho letto tutti i post qui in SO, GoF e wikipedia ma in realtà non ha senso!

Dalla mia comprensione, Entrambi i modelli punto in un tipo esistente, sia scindere un'astrazione dalla sua attuazione mi manca un punto?

Ecco da GoF:

La differenza fondamentale tra questi modelli sta nella loro intenti. L'adattatore si concentra sulla risoluzione delle incompatibilità tra due interfacce esistenti . Non si concentra sul modo in cui queste interfacce sono implementate, né considera come potrebbero evolversi indipendentemente. È un modo di creare due classi progettate in modo indipendente che funzionano insieme senza lo che reimplementa l'una o l'altra. Bridge, d'altra parte, collega un'astrazione e le sue (potenzialmente numerose) implementazioni. Lo standard fornisce un'interfaccia stabile ai client anche se consente di variare le classi che lo implementano. Inoltre, supporta le nuove implementazioni come il sistema si evolve.

Non capisco pienamente la dichiarazione di cui sopra,

1. Vuol dire che se ho variare l'adaptee o modificare l'implementazione del l'interfaccia originale in fase di progettazione, allora è Ponte modello ?
2. Le differenze suona banale, ci sono altre differenze nell'implementazione/abstcation ?
3. Come si può sapere quale implementazione viene utilizzata dopo lo sviluppo ?
4. Qualcuno può darmi un buon esempio di schema del bridge e come è possibile modificare durante il ciclo di vita del software?

Aggiornamento:

Sempre da GoF:

Ricordate che un adattatore fa due interfacce esistenti lavorano insieme in contrasto con la definizione di uno completamente nuovo.

Vuol dire che cambiando l'interfaccia esistente in modo che possa lavorare con un'altra interfaccia è un'implementazione di Adapter?

Update2:

Appena trovato questo incredibile articolo: Illustrated GOF Design Patterns in C#

Questa è vera struttura Ponte di picchiettio:

mi mancava il fatto che il modello di ponte consente di combinare le diverse astrazioni e le implementazioni e estendere in modo indipendente in modo indipendente

Answer 1

Penso che tu non abbia puro schema GoF qui. È qualcosa tra Decorator e Adapter. Stai cambiando l'interfaccia del client di servizio (adattandolo alle tue esigenze). Ma anche tu stai aggiungendo nuove responsabilità al client (la registrazione e la gestione degli errori) - questo è un elemento decorativo. Se vuoi rimanere con l'interfaccia di servizio originale, sarebbe puro Decorator.

AGGIORNAMENTO: Qualsiasi utilizzo dell'ereditarietà non significa che stiamo utilizzando un modello GoF. Ci sono diverse cose che mancano all'architettura corrente di Bridge:

• Gerarchia di implementazioni. La tua interfaccia di servizio dovrebbe definire alcune operazioni di basso livello. E dovresti avere diverse implementazioni di servizio.
• L'astrazione dovrebbe definire l'interfaccia di alto livello. Di solito queste interfacce non hanno un aspetto simile all'interfaccia di implementazione (l'interfaccia client è simile all'interfaccia di servizio, esiste allo stesso livello di astrazione).
• Le implementazioni di astrazione devono utilizzare l'interfaccia di servizio per implementare operazioni di alto livello (ad esempio non aggiungono alcune responsabilità al servizio, implementano cose diverse, cose di alto livello).

Answer 2

Mi è stato spiegato il patter del ponte n come intenzione di combinare due gerarchie di classi con scopi diversi. Ad esempio, si consideri che si sta scrivendo un framework di finestre con diversi tipi di controlli e supporto per diversi sistemi di finestre. Avresti un albero di classi per i controlli e un altro per astrarre le differenze tra i sistemi di finestre. Ora se si desidera aggiungere il supporto per un altro sistema di finestre, è sufficiente aggiungerlo a quel lato della gerarchia e, se si desidera aggiungere nuovi controlli, aggiungerli al loro lato. Il "ponte" esiste tra le classi superiori delle due gerarchie, in cui la classe di controllo ha accesso alle funzioni astratte definite dalla classe base della gerarchia di classi che implementa il supporto per i vari sistemi di finestre.

Con il modello di adattatore non si desidera combinare due gerarchie di classi con intenzioni diverse, ma adattare una classe per lavorare con la propria interfaccia. Suppongo che se si supporta un solo sistema a finestra singola nell'esempio sopra e non si inserisca una classe astratta tra parentesi per mantenere l'estensibilità, si tratterebbe di un adattatore anziché di un bridge.

Answer 3

Questo è stato discusso in precedenza qui - Difference between Bridge pattern and Adapter pattern - La vera citazione che vuoi da GoF è "Adapter rende le cose funzionano dopo che sono stati progettati; Ponte li fa lavorare prima che siano [GoF, P219]

.

L'ultima domanda ottiene un sì - un adattatore viene utilizzato per rendere piacevoli due elementi altrimenti sgradevoli di un sistema insieme senza cambiare la loro funzionalità fondamentale oltre a sostituire l'unione delle loro funzionalità -

Un pattern bridge viene solitamente utilizzato per gestire con problemi nella progettazione iniziale in cui il modello mentale presentato al consumatore potrebbe essere wi È molto diverso dal modello che realizza l'implementazione del modello dei consumatori. Si consideri una libreria matematica ad alte prestazioni che sembra la stessa attraverso una vasta gamma di processori - si vuole solo moltiplicare le matrici, ma dietro le quinte ci sono tutti i tipi di cruft coinvolgono swizzling, flussi di dati in parallelo, comportamenti strani per evitare stalli gasdotti, e tutto fatto in modo diverso su 3+ realizzazioni di un nucleo superscaler ad alte prestazioni - e questo è solo Intel :-(