Memisahkan suatu abstraksi dari pelaksanaannya sehingga dua dapat bervariasi secara independen.
Publikasikan antarmuka dalam hirarki warisan, dan mengubur implementasi dalam hirarki warisan sendiri.
Luar enkapsulasi, untuk isolasi
Masalah
"Pengerasan arteri software" telah terjadi dengan menggunakan subclassing dari kelas dasar abstrak untuk menyediakan implementasi alternatif. Ini terkunci pada mengikat antara interface dan implementasi saat kompilasi. Abstraksi dan implementasi tidak dapat mandiri diperpanjang atau terdiri.
Pertimbangkan domain dari "benang penjadwalan".
Ada dua jenis benang penjadwal, dan dua jenis sistem operasi atau "platform". Mengingat pendekatan ini untuk spesialisasi, kita harus mendefinisikan kelas untuk setiap permutasi dari dua dimensi tersebut. Jika kita menambahkan platform baru (katakanlah ... Jawa Virtual Machine), apa yang akan hirarki kami terlihat seperti?
Bagaimana jika kita memiliki tiga jenis benang penjadwal, dan empat jenis platform? Bagaimana jika kita memiliki lima jenis benang penjadwal, dan sepuluh jenis platform? Jumlah kelas kita harus mendefinisikan adalah produk dari jumlah skema penjadwalan dan jumlah platform.
Pola desain Bridge mengusulkan refactoring hirarki warisan eksponensial peledak ini menjadi dua hirarki orthogonal - satu untuk abstraksi platform-independen, dan yang lainnya untuk implementasi tergantung platform.
Terurai interface dan implementasi komponen ke dalam hierarki kelas orthogonal. Kelas antarmuka berisi pointer ke kelas implementasi abstrak. Pointer ini diinisialisasi dengan sebuah instance dari kelas implementasi konkret, tetapi semua interaksi berikutnya dari kelas antarmuka ke kelas implementasi terbatas pada abstraksi dipertahankan di kelas dasar pelaksanaan. Klien berinteraksi dengan kelas antarmuka, dan pada gilirannya "delegasi" semua permintaan untuk kelas implementasi.
Objek antarmuka adalah "pegangan" yang dikenal dan digunakan oleh klien; sedangkan objek pelaksanaan, atau "tubuh", yang aman dikemas untuk memastikan bahwa hal itu mungkin terus berkembang, atau seluruhnya diganti (atau bersama saat run-time.
Menggunakan pola Bridge ketika:
Anda ingin run-time mengikat pelaksanaan,
Anda memiliki proliferasi kelas yang dihasilkan dari antarmuka ditambah dan banyak implementasi,
Anda ingin berbagi sebuah implementasi antara beberapa objek,
Anda perlu untuk memetakan hierarki kelas orthogonal.
Konsekuensi meliputi:
decoupling antarmuka objek,
ditingkatkan diperpanjang (Anda dapat memperpanjang (yaitu subclass) abstraksi dan implementasi hirarki independen),
menyembunyikan rincian dari klien.
Bridge adalah sinonim untuk "menangani / body" idiom. Ini adalah mekanisme desain yang merangkum kelas implementasi dalam kelas antarmuka. Yang pertama adalah tubuh, dan yang terakhir adalah pegangan. Pegangan tersebut dilihat oleh pengguna sebagai kelas yang sebenarnya, tetapi pekerjaan dilakukan di dalam tubuh. "Pegangan / body kelas idiom dapat digunakan untuk menguraikan abstraksi kompleks menjadi lebih kecil, kelas lebih mudah dikelola. Idiom dapat mencerminkan pembagian sumber daya tunggal dengan beberapa kelas yang mengontrol akses ke sana (misalnya menghitung referensi).”
Struktur
Klien tidak mau berurusan dengan rincian tergantung platform. Pola Bridge merangkum kompleksitas ini di belakang sebuah abstraksi "wrapper".
Jembatan menekankan mengidentifikasi dan decoupling "antarmuka" abstraksi dari "implementasi" abstraksi.
Contoh
Pola Bridge decouples abstraksi dari pelaksanaannya, sehingga dua dapat bervariasi secara independen. Sebuah switch lampu rumah tangga mengendalikan, kipas langit-langit, dll adalah contoh dari Jembatan. Tujuan dari saklar untuk menghidupkan perangkat atau menonaktifkan. Saklar yang sebenarnya dapat diimplementasikan sebagai rantai tarik, sederhana dua posisi saklar, atau berbagai switch dimmer.
Periksa daftar
Memutuskan apakah dua dimensi ortogonal ada di domain. Konsep-konsep yang independen bisa menjadi: abstraksi / platform, atau domain / infrastruktur, atau front-end / back-end, atau antarmuka / implementasi.
Desain pemisahan keprihatinan: apa klien inginkan, dan apa yang platform menyediakan.
Merancang antarmuka platform yang berorientasi yang minim, perlu, dan cukup. Tujuannya adalah untuk memisahkan abstraksi dari platform.
Mendefinisikan kelas turunan dari antarmuka untuk setiap platform.
Buat abstraksi kelas dasar yang "memiliki" objek Platform dan delegasi platform yang berorientasi fungsi untuk itu.
Menentukan spesialisasi dari kelas abstraksi jika diinginkan.
Aturan praktis
Adapter membuat hal-hal bekerja setelah mereka dirancang; Bridge membuat mereka bekerja sebelum mereka.
Jembatan dirancang muka untuk membiarkan abstraksi dan pelaksanaannya bervariasi secara independen. Adaptor dipasang untuk membuat kelas tidak berhubungan bekerja sama.
Negara, Strategi, Bridge (dan untuk beberapa derajat Adapter) memiliki struktur solusi yang sama. Mereka semua elemen bagian dari "pegangan / body" idiom. Mereka berbeda dalam maksud - yaitu, mereka memecahkan masalah yang berbeda.
Struktur Negara dan Bridge adalah identik (kecuali bahwa Bridge mengakui hirarki kelas amplop, sedangkan Negara memungkinkan hanya satu). Dua pola menggunakan struktur yang sama untuk memecahkan masalah yang berbeda: Negara memungkinkan perilaku obyek untuk mengubah bersama dengan keadaan, sementara niat Bridge adalah untuk memisahkan suatu abstraksi dari pelaksanaannya sehingga dua dapat bervariasi secara independen.
Jika kelas antarmuka mendelegasikan penciptaan kelas pelaksanaannya (bukan menciptakan / kopling sendiri langsung), maka desain biasanya menggunakan pola Pabrik Abstrak untuk membuat objek implementasi.
Posting Komentar
Peraturan Berkomentar :
✔ Berkomentarlah Sesuai Artikel Diatas
✔ Untuk Berkomentar Gunakan (OpenID / Name URL / Google+)
✔ Berkomentarlah Menggunakan Bahasa Yang Jelas
✔ Relevan
✔ Sopan
✖ SPAM
✖ Link Aktif (Live Link)
✖ Promosi (Iklan)
✖ OOT (Out Of Topic)