UGIdotNET Home UGIdotNET Home
UGIdotNET Blogs UGIdotNET Blogs
UGIdotNET Forum UGIdotNET Forum
MSDN Architetti MSDN Architetti
Visualizza Modifiche Visualizza Modifiche
Modifica Modifica
Stampa Stampa
Modifiche Recenti Modifiche Recenti
Sottoscrizioni Sottoscrizioni
Ufficio Oggetti Smarriti Ufficio Oggetti Smarriti
Cerca Riferimenti Cerca Riferimenti
Rinomina Rinomina
Cerca

Versioni

27/05/2006 16.08.17
LucaMinudel-88.149.166.101
26/05/2006 15.39.41
147.163.26.198
31/12/2005 14.11.15
LucaMinudel-151.47.139.218
25/12/2005 15.41.07
LucaMinudel-151.47.144.232
Elenco completo versioni Elenco completo versioni
Pattern Bridge
.
Summary Un design pattern che disaccoppia un'astrazione dalla sua implementazione in modo che possano evolvere autonomamente.

Conosciuto anche come

Handle/Body, Driver.

Intento

Il design pattern Bridge disaccoppia un'astrazione (RealAbstraction) dalla sua implementazione (ConcreteImplementatorA) cosicchè entrambe possano variare ed evolvere in modo indipendente ed autonomo e che sia possibile sostituire l'implementazione (con ConcreteImplementatorB) senza conseguenze per l'utilizzatore (Client).

La classe ConcreteImplementatorA che determina l'implementazione stabilita a design-time attraverso l'ereditarietà quindi questo design pattern è classificato rispetto allo scopo (vedi ClassificazioneDeiDesignPattern#ClassiOggetti) come rivolto alle classi. Rispetto al fine questo questo design ClassificazioneDeiDesignPattern#Strutturali.

Diagramma UML

Un'altro diagramma equivalente qui .

Motivazione

Il design pattern Bridge è utile quando:

  • l'implementazione (ConcreteImplementatorA ma anche Implementator) può cambiare nel tempo e non si vuole che questo renda necessarie modifiche all'utilizzatore (Client);
  • sono disponibili più implementazioni (ConcreteImplementatorA e ConcreteImplementatorB) e l'implementazione utilizzata è determinata a run-time, così come accade per i driver di una periferica;
  • l'implementazione (Implementator) e l'astrazione (Abstraction) devono essere derivabili separatamente ottenendo due GerarchieDiClassi distinte;
  • si desidera condividere una istanza della implementazione (ConcreteImplementatorA) tra più oggetti distinti (RealAbstraction).

Esempi d'uso in .NET

L'implementazione MONO di .NET impiega questo design pattern nel namespace System.Windows.Forms ad esempio per la classe Form la cui implementazione dipende dal Toolkit grafico disponibile in un dato sistema operativo (Win32 per Windows, X11 per Unix e Linux, nativo per Mac OS X, etc.).

Per ottimizzare il tipo oggetto String ogni istanza di string referenzia l'implementazione di una stringa reale che in caso di copia della variabile String viene condivisa.

  • questo caso non è + simile al PatternFlyWeight che ha lo scopo di evitare che la stessa stringa venga duplicata in memoria diverse volte (ogni volta che viene assegnata o passata come paramtro ad esempio)? Mentre la necessità di evolvere indipendentemente la implementazione interna della stringa dalla sua rappresentazione non un problema (la prima è già incapsulata dall'oggetto stringa e sia implementazione che astrazione sono modificate e rilasciate insieme dallo stesso vendor e quindi non ci sono problemi di evoluzioni divergenti) ?

Note sulla implementazione in .NET

In .NET e C# non è disponibile l'EreditarietàPrivata, per ottenere il medesimo effetto è possibile applicare questo design pattern.

Del codice .NET di esempio è disponibile qui .

Relazione con altri design pattern

Vedi la mappa della RelazioneTraDesignPattern.

Approfondimenti

Questo design pattern viene in aiuto anche quando è necessario modificare o evolvere l'implementazione (ConcreteImplementatorA) di una astrazione (Abstraction) senza dover ricompilare le classi (Client) che lo utilizzano. Lo stesso risultato in .NET si ottiene mettendo l'implementazione (ConcreteImplementatorA) in un altro Assembly e referenziandolo, il meccanismo di load dinamico delle dll e del versioning permetterà di caricare la nuova versione dell'implementazione senza ricompilare l'assembly dell'utilizzatore. Questa possibilità è alla base del ParadigmaDiProgrammazioneAComponenti, una caratteristica innovativa diffusa nelle applicazioni commerciali da Microsoft e solo successivamente adottata anche dai sistemi Unix e Linux.

Quando l'implementazione è una e una sola a solo uso della data astrazione, applicare questo design pattern non da alcun beneficio.

Domande di approfondimento

  • Che differenza chè tra questo design pattern e il PatternAdapter?
  • Che differenza chè tra questo design pattern e il PatternProxy?
  • Che differenza chè tra questo design pattern e il PatternStrategy?
  • Come, quando e dove decidi quale classe Implementor istanziare se cen'è più di una (ConcreteImplementatorA, ConcreteImplementatorB, ...)?

Link

VediAnche CatalogoDeiDesignPattern

UGIdotNETWiki

UGIdotNETWiki è il WikiWiki italiano dedicato a .NET

Se è la prima volta che senti parlare di Wiki, leggi il BenvenutoAiVisitatori e WikiInUnMinuto, oppure il ManualePassoPassoDelWiki.

Argomenti Recenti

  • PatternBridge
© 2008 User Group Italiano UGIdotNET. Tutti i diritti riservati. Note legali