Perbedaan antara pola Bridge dan pola Adaptor

Apa perbedaan antara pola Bridge dan Adaptor?

"Adaptor membuat segala sesuatunya berfungsi setelah dirancang; Bridge membuatnya berfungsi sebelum mereka. [GoF, p219]"

Secara efektif, pola Adaptor berguna ketika Anda memiliki kode yang ada, baik itu pihak ketiga, atau internal, tetapi di luar kendali Anda, atau tidak dapat diubah untuk memenuhi antarmuka yang Anda perlukan. Misalnya, kami memiliki SuperWeaponsArray yang dapat mengontrol berbagai perangkat kiamat.

public class SuperWeaponsArray {
  /*...*/

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

Bagus. Kecuali kami menyadari bahwa kami memiliki perangkat nuklir di gudang senjata kami yang jauh sebelum konversi ke antarmuka Senjata. Tapi kami benar-benar ingin bekerja di sini ... jadi apa yang harus kami lakukan ... selipkan!

NukeWeaponsAdaptor - berbasis kelas Nuke kami, tetapi mengekspor antarmuka Weapon. Manis, sekarang kita pasti bisa menghancurkan dunia. Sepertinya sedikit kludge, tapi itu membuat semuanya bekerja.

The Bridge Pola adalah sesuatu yang Anda menerapkan depan - jika Anda tahu Anda memiliki dua hirarki orthogonal, ia menyediakan cara untuk memisahkan antarmuka dan implementasi sedemikian rupa bahwa Anda tidak mendapatkan jumlah gila kelas. Katakanlah Anda memiliki:

MemoryMappedFile dan DirectReadFile jenis objek file. Katakanlah Anda ingin dapat membaca file dari berbagai sumber (Mungkin implementasi Linux vs. Windows, dll.). Bridge membantu Anda menghindari akhir dengan:

MemoryMappedWindowsFile MemoryMappedLinuxFile DirectReadWindowsFile DirectReadLinuxFile

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

Pola Adaptor lebih tentang membuat kode Anda yang ada berfungsi dengan sistem atau antarmuka yang lebih baru.

Jika Anda memiliki seperangkat API layanan web standar perusahaan yang ingin Anda tawarkan ke antarmuka ekstensibilitas yang ada dari aplikasi lain, Anda dapat mempertimbangkan untuk menulis sekumpulan adaptor untuk melakukan ini. Perhatikan bahwa ada area abu-abu dan ini lebih tentang bagaimana Anda secara teknis mendefinisikan pola, karena pola lain seperti fasad serupa.

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

Pola Bridge akan memungkinkan Anda untuk memiliki implementasi alternatif dari suatu algoritma atau sistem.

Meskipun bukan contoh pola Bridge klasik, bayangkan jika Anda memiliki beberapa implementasi penyimpanan data: satu efisien dalam ruang, yang lain efisien dalam kinerja mentah ... dan Anda memiliki kasus bisnis untuk menawarkan baik dalam aplikasi atau kerangka kerja Anda .

Terkait pertanyaan Anda, "di mana saya dapat menggunakan pola yang mana", jawabannya adalah, di mana pun itu masuk akal untuk proyek Anda! Mungkin pertimbangkan untuk menawarkan suntingan klarifikasi untuk memandu diskusi di mana Anda yakin perlu menggunakan salah satunya.

Adaptor:

1. Ini adalah pola struktural
2. Berguna untuk bekerja dengan dua antarmuka yang tidak kompatibel

Diagram UML: dari artikel dofactory :

Target : menentukan antarmuka khusus domain yang digunakan Klien.

Adaptor : menyesuaikan antarmuka Adaptee dengan antarmuka Target.

Adaptee : mendefinisikan antarmuka yang ada yang perlu diadaptasi.

Klien : berkolaborasi dengan objek yang sesuai dengan antarmuka Target.

Contoh:

Persegi dan Persegi Panjang adalah dua bentuk berbeda dan mendapatkan area () dari masing-masing membutuhkan metode yang berbeda. Tapi tetap saja Square bekerja pada antarmuka Rectangle dengan konversi beberapa properti.

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);
    }
}

Menjembatani:

1. Itu adalah pola struktural
2. itu memisahkan abstraksi dari implementasinya dan keduanya dapat bervariasi secara independen
3. Ini dimungkinkan karena komposisi telah digunakan sebagai pengganti pewarisan

EDIT: (sesuai saran @quasoft)

Anda memiliki empat komponen dalam pola ini.

1. Abstraksi : Ini mendefinisikan antarmuka

2. RefinedAbstraction : Ini mengimplementasikan abstraksi:

3. Implementor : Ini mendefinisikan antarmuka untuk implementasi

4. ConcreteImplementor : Ini mengimplementasikan antarmuka Implementor.

Potongan kode:

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

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

Posting terkait:

Kapan Anda menggunakan Pola Jembatan? Apa bedanya dengan pola Adaptor?

Perbedaan utama: dari artikel pembuatan sumber

1. Adaptor membuat segala sesuatunya berfungsi setelah dirancang; Bridge membuat mereka bekerja sebelum mereka bekerja.
2. Bridge dirancang di depan agar abstraksi dan implementasinya bervariasi secara independen. Adaptor dipasang untuk membuat kelas yang tidak terkait berfungsi bersama.

Postingan ini sudah ada cukup lama. Namun, penting untuk dipahami bahwa fasad agak mirip dengan adaptor tetapi tidak persis sama. Adaptor "menyesuaikan" kelas yang ada ke kelas klien yang biasanya tidak kompatibel. Misalkan Anda memiliki sistem alur kerja lama yang digunakan aplikasi Anda sebagai klien. Perusahaan Anda mungkin dapat mengganti sistem alur kerja dengan yang baru "tidak kompatibel" (dalam hal antarmuka). Dalam kebanyakan kasus, Anda dapat menggunakan pola adaptor dan menulis kode yang benar-benar memanggil antarmuka mesin alur kerja baru. Jembatan umumnya digunakan dengan cara yang berbeda. Jika Anda benar-benar memiliki sistem yang perlu bekerja dengan sistem file yang berbeda (misalnya disk lokal, NFS, dll.) Anda dapat menggunakan pola jembatan dan membuat satu lapisan abstraksi untuk bekerja dengan semua sistem file Anda. Ini pada dasarnya akan menjadi kasus penggunaan sederhana untuk pola jembatan. Facade dan adaptor berbagi beberapa properti tetapifasad biasanya digunakan untuk menyederhanakan antarmuka / kelas yang ada . Pada hari-hari awal EJB tidak ada panggilan lokal untuk EJB. Pengembang selalu mendapatkan rintisan, mempersempitnya, dan menyebutnya "pseudo-remote". Hal ini sering kali menyebabkan masalah kinerja (khususnya ketika benar-benar dipanggil melalui kabel). Pengembang berpengalaman akan menggunakan pola fasad untuk menyediakan antarmuka yang sangat kasar kepada klien. Fasad ini kemudian akan melakukan beberapa panggilan ke metode berbeda yang lebih halus. Secara keseluruhan, ini sangat mengurangi jumlah panggilan metode yang diperlukan dan meningkatkan kinerja.

Bridge ditingkatkan Adaptor. Bridge menyertakan adaptor dan menambahkan fleksibilitas tambahan padanya. Berikut adalah bagaimana elemen dari peta jawaban Ravindra di antara pola:

      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

Dalam jawaban teratas, @James mengutip kalimat dari GoF, halaman 219. Saya pikir ada baiknya mereproduksi penjelasan lengkapnya di sini.

Adaptor versus Bridge

Pola Adaptor dan Bridge memiliki beberapa atribut umum. Keduanya mempromosikan fleksibilitas dengan memberikan tingkat tipuan ke objek lain. Keduanya melibatkan permintaan penerusan ke objek ini dari antarmuka selain miliknya.

Perbedaan utama antara pola-pola ini terletak pada maksudnya. Adaptor berfokus pada penyelesaian ketidakcocokan antara dua antarmuka yang ada. Itu tidak fokus pada bagaimana antarmuka tersebut diimplementasikan, juga tidak mempertimbangkan bagaimana mereka mungkin berkembang secara independen. Ini adalah cara untuk membuat dua kelas yang dirancang secara independen berfungsi bersama tanpa menerapkan ulang satu atau lainnya. Bridge, di sisi lain, menjembatani abstraksi dan (berpotensi banyak) implementasinya. Ini menyediakan antarmuka yang stabil untuk klien meskipun memungkinkan Anda memvariasikan kelas yang menerapkannya. Ini juga mengakomodasi implementasi baru seiring berkembangnya sistem.

Akibat perbedaan ini, Adaptor dan Bridge sering digunakan pada titik yang berbeda dalam siklus hidup perangkat lunak. Adaptor sering kali diperlukan saat Anda menemukan bahwa dua kelas yang tidak kompatibel harus bekerja bersama, umumnya untuk menghindari replikasi kode. Koplingnya tidak terduga. Sebaliknya, pengguna jembatan memahami sebelumnya bahwa abstraksi harus memiliki beberapa implementasi, dan keduanya dapat berkembang secara independen. Pola Adaptor membuat segala sesuatunya berfungsi setelah dirancang; Bridge membuat mereka bekerja sebelum mereka bekerja. Itu tidak berarti Adapter entah bagaimana lebih rendah dari Bridge; setiap pola hanya membahas masalah yang berbeda.

Misalkan Anda memiliki kelas Shape abstrak dengan fungsionalitas gambar (generik / abstrak) dan Circle yang mengimplementasikan Shape. Pola jembatan secara sederhana adalah pendekatan abstraksi dua arah untuk memisahkan implementasi (menggambar dalam Circle) dan fungsionalitas generik / abstrak (menggambar dalam kelas Shape).

Apa sebenarnya artinya Sekilas, ini terdengar seperti sesuatu yang sudah Anda buat (dengan inversi ketergantungan). Jadi jangan khawatir tentang memiliki basis kode yang lebih sedikit atau lebih modular. Tapi ada filosofi yang lebih dalam di baliknya.

Dari pemahaman saya, kebutuhan pola penggunaan mungkin muncul ketika saya perlu menambahkan kelas baru yang terkait erat dengan sistem saat ini (seperti RedCircle atau GreenCircle) dan yang berbeda hanya dengan satu fungsi (seperti warna). Dan saya akan membutuhkan pola Bridge terutama jika kelas sistem yang ada (Lingkaran atau Bentuk) akan sering diubah dan Anda tidak ingin kelas yang baru ditambahkan terpengaruh dari perubahan tersebut. Jadi itulah mengapa fungsionalitas gambar generik diabstraksi menjadi antarmuka baru sehingga Anda dapat mengubah perilaku menggambar secara independen dari Bentuk atau Lingkaran.