Differenza tra il modello Bridge e il modello Adapter

Question

Qual è la differenza tra i modelli Bridge e Adapter?

Answer 1

  

" L'adattatore fa funzionare le cose dopo che sono state progettate; Bridge li rende   lavorare prima che lo siano. [GoF, p219] "

In effetti, il modello Adattatore è utile quando disponi di codice esistente, sia esso di terze parti o interno, ma fuori dal tuo controllo o altrimenti non modificabile per soddisfare completamente l'interfaccia di cui hai bisogno a. Ad esempio, abbiamo un SuperWeaponsArray in grado di controllare una vasta gamma di dispositivi del giorno del giudizio.

public class SuperWeaponsArray {
  /*...*/

  public void destroyWorld() {
    for (Weapon w : armedWeapons) {
      w.fire();
    }
  }
}

Grande. Solo che ci rendiamo conto di avere un dispositivo nucleare nel nostro arsenale che precede enormemente la conversione all'interfaccia dell'arma. Ma ci piacerebbe davvero che funzionasse qui ... quindi cosa facciamo ... incastriamolo!

NukeWeaponsAdaptor - basato sulla nostra classe Nuke, ma che esporta l'interfaccia Weapon. Dolce, ora possiamo sicuramente distruggere il mondo. Sembra un po 'difficile, ma fa funzionare le cose.

---

Il modello Bridge è qualcosa che implementi in anticipo - se sai di avere due gerarchie ortogonali, fornisce un modo per disaccoppiare l'interfaccia e l'implementazione in modo tale da non ottenere un numero folle di classi. Diciamo che hai:

Tipi di oggetti file MemoryMappedFile e DirectReadFile. Diciamo che vuoi essere in grado di leggere file da varie fonti (forse implementazioni Linux vs Windows, ecc.). Bridge ti aiuta a evitare di finire con:

MemoryMappedWindowsFile MemoryMappedLinuxFile DirectReadWindowsFile DirectReadLinuxFile

Answer 2

http://en.wikipedia.org/wiki/Adapter_pattern

Il modello dell'adattatore riguarda più il funzionamento del codice esistente con un sistema o un'interfaccia più recenti.

Se si dispone di un set di API di servizi Web standard aziendali che si desidera offrire all'interfaccia di estensibilità esistente di un'altra applicazione, è possibile prendere in considerazione la possibilità di scrivere un set di adattatori per farlo. Nota che c'è un'area grigia e questo riguarda di più il modo in cui definisci tecnicamente il motivo, poiché altri motivi come la facciata sono simili.

http://en.wikipedia.org/wiki/Bridge_pattern

Il modello Bridge ti consentirà di avere implementazioni alternative di un algoritmo o sistema.

Sebbene non sia un classico esempio di modello Bridge, immagina di avere alcune implementazioni di un archivio dati: uno è efficiente nello spazio, l'altro è efficiente nelle prestazioni grezze ... e hai un business case per offrire entrambi nel tuo app o framework.

In termini di domanda, "dove posso usare quale modello", la risposta è, ovunque abbia senso per il tuo progetto! Forse potresti offrire una modifica di chiarimento per guidare la discussione su dove ritieni di dover usare l'uno o l'altro.

Answer 3

Adapter:

1. È un modello strutturale
2. È utile lavorare con due interfacce incompatibili

Diagramma UML: dall'articolo dofactory :

Targeting : definisce l'interfaccia specifica del dominio utilizzata dal Cliente.

Adapter : adatta l'interfaccia Adatta all'interfaccia di destinazione.

Adaptee : definisce un'interfaccia esistente che deve essere adattata.

Client : collabora con oggetti conformi all'interfaccia Target.

Esempio:

Quadrato e Rettangolo sono due forme diverse e ottenere un'area () di ognuna di esse richiede metodi diversi. Ma Square funziona ancora sull'interfaccia Rectangle con la conversione di alcune proprietà.

public class AdapterDemo{
    public static void main(String args[]){
        SquareArea s = new SquareArea(4);
        System.out.println("Square area :"+s.getArea());
    }
}

class RectangleArea {
    public int getArea(int length, int width){
        return length * width;
    }
}

class SquareArea extends RectangleArea {

    int length;
    public SquareArea(int length){
        this.length = length;
    }
    public int getArea(){
        return getArea(length,length);
    }
}

Ponte:

1. È modello strutturale
2. separa un'astrazione dalla sua implementazione ed entrambe possono variare in modo indipendente
3. È possibile perché la composizione è stata utilizzata al posto dell'eredità

EDIT: (come da suggerimento @quasoft)

Hai quattro componenti in questo modello.

1. Astrazione : definisce un'interfaccia

2. RefinedAbstraction : implementa l'astrazione:

3. Implementor : definisce un'interfaccia per l'implementazione

4. ConcreteImplementor : implementa l'interfaccia Implementor.

Snippet di codice:

Gear gear = new ManualGear();
Vehicle vehicle = new Car(gear);
vehicle.addGear();

gear = new AutoGear();
vehicle = new Car(gear);
vehicle.addGear();

Post correlato:

Quando usi il modello Bridge? In cosa differisce dal modello dell'adattatore?

Differenze chiave: da sourcemaking articolo

1. L'adattatore fa funzionare le cose dopo che sono state progettate; Bridge li fa funzionare prima che lo siano.
2. Bridge è progettato in anticipo per consentire all'astrazione e all'implementazione di variare in modo indipendente. L'adapter viene adattato per consentire alle classi non correlate di lavorare insieme.

Answer 4

Questo post è in circolazione da un po 'di tempo. Tuttavia, è importante capire che una facciata è in qualche modo simile a un adattatore ma non è esattamente la stessa cosa. Un adattatore "adatta" una classe esistente in una classe client solitamente non compatibile. Supponiamo che tu abbia un vecchio sistema di flusso di lavoro che l'applicazione utilizza come client. La tua azienda potrebbe eventualmente sostituire il sistema del flusso di lavoro con un nuovo "incompatibile" uno (in termini di interfacce). Nella maggior parte dei casi, è possibile utilizzare il modello di adattatore e scrivere codice che in realtà chiama le interfacce del nuovo motore del flusso di lavoro. Un ponte viene generalmente utilizzato in modo diverso. Se in realtà disponi di un sistema che deve funzionare con file system diversi (ad esempio disco locale, NFS, ecc.) Puoi utilizzare il modello bridge e creare un livello di astrazione per lavorare con tutti i tuoi file system. Questo sarebbe fondamentalmente un semplice caso d'uso per il modello di ponte. La facciata e l'adattatore condividono alcune proprietà, ma le facciate vengono generalmente utilizzate per semplificare un'interfaccia / classe esistente . All'inizio degli EJB non c'erano chiamate locali per gli EJB. Gli sviluppatori ottennero sempre lo stub, lo restrinsero e lo chiamarono "pseudo-remoto". Questo spesso ha causato problemi di prestazioni (specialmente se realmente chiamati via cavo). Gli sviluppatori esperti utilizzerebbero il modello di facciata per fornire al client un'interfaccia molto approssimativa. A sua volta, questa facciata avrebbe fatto più chiamate a diversi metodi più precisi. Tutto sommato, questo ha notevolmente ridotto il numero di chiamate al metodo richieste e un aumento delle prestazioni.

Answer 5

Supponi di avere una classe Shape astratta con una funzionalità di disegno (generica / astratta) e un Cerchio che implementa la Shape. Il modello a ponte è semplicemente un approccio di astrazione bidirezionale per disaccoppiare l'implementazione (disegno in Cerchio) e la funzionalità generica / astratta (disegno nella classe Forma).

Cosa significa veramente? A prima vista, sembra qualcosa che stai già facendo (per inversione di dipendenza). Quindi non preoccuparti di avere una base di codice meno ridig o più modulare. Ma è una filosofia un po 'più profonda dietro di essa.

Dalla mia comprensione, la necessità del modello di utilizzo potrebbe emergere quando ho bisogno di aggiungere nuove classi che sono strettamente correlate al sistema attuale (come RedCircle o GreenCircle) e che differiscono per una sola funzionalità (come il colore). E avrò bisogno del modello Bridge in particolare se le classi di sistema esistenti (Circle o Shape) devono essere cambiate frequentemente e non si desidera che le nuove classi aggiunte siano influenzate da tali cambiamenti. Ecco perché la funzionalità di disegno generico viene sottratta in una nuova interfaccia in modo da poter modificare il comportamento del disegno indipendentemente da Shape o Circle.

Answer 6

Bridge è migliorato Adapter. Bridge include l'adattatore e aggiunge ulteriore flessibilità. Ecco come gli elementi della mappa delle risposte di Ravindra tra i pattern:

      Adapter  |    Bridge
    -----------|---------------
    Target     | Abstraction
    -----------|---------------
               | RefinedAbstraction
               |
               |   This element is Bridge specific. If there is a group of 
               |   implementations that share the same logic, the logic can be placed here.
               |   For example, all cars split into two large groups: manual and auto. 
               |   So, there will be two RefinedAbstraction classes.
    -----------|--------------- 
    Adapter    | Implementor
    -----------|---------------
    Adaptee    | ConcreteImplementor