Bridge Pattern “Si Jembatan”

This entry was posted on Februari 7, 2009, in Design Pattern. Bookmark the permalink. 3 Komentar

Bridge (jembatan)

Bridge Pattern ini merupakan pattern yang kuat (powerfull) dan sering

digunakan dalam pengembangan. Dan ini sebanding dengan usaha untuk mempelajarinya yang cukup
menantang.

Untuk memahami design pattern yang satu ini, kita perlu melihat makna decouple (tidak berpasangan),
abstraction (abstraksi), dan implementation (implementasi) dari sisi yang berbeda terlebih dahulu.

Decouple adalah bagaimana objek tidak terhubung satu sama lain, berdiri sendiri (independent), terpisah.
Abstraksi adalah konsep bagaimana antar objek saling terhubung.

Sedangkan “implementasi” janganlah dipandang sebagai penurunan dari suatu kelas abstrak (concrete
class). Pandanglah “implementasi” sebagai objek lain yang digunakan oleh kelas abstrak (dan
turunannya) untuk mengimplementasi dirinya (“nya” ditujukan untuk kelas abstrak).

Dalam sebagian besar tutorial, bridge pattern didefinisikan sebagai

pattern yang berusaha memisahkan antara abstraksi dan implementasi.

Bingung? Hehe.. Namanya juga teori, biasanya mengawang-awang jika tidak diaplikasikan. Yuk kita
aplikasikan!

(Untuk contoh bridge pattern ini, saya ambil dari buku Design Patterns JAVA Workbook .)
Misalkan kita punya modal diagram kelas yang pada superclassnya terdapat sebuah kelas abstrak
“MachineController”. Nah, di dalam MachineController ini terdapat beberapa abstractdan concrete
method. Salah satu concrete method pada MachineController, yaitu inputfull, menggunakan hasil dari salah
satu abstract method “getQueueMax()”.
public boolean inputfull(){
return getQueueMax() >= getQueue.size();
}
Dan selayaknya sebuah abstract method, method getQueueMax() ini baru akan didefinisikan dalam kelas
yang turunan MachineController, yaitu StarPressController dan ShellController. Kedua kelas turunan ini
mendefinisikan method getQueueMax() dengan cara yang berbeda. Berikut ini adalah diagram kelas yang
dimaksudkan :

Sampai disini, masih baik-baik saja.

Kemudian pada suatu hari, kita baru menyadari bahwa kita membutuhkan mekanisme (controller) yang
berbeda pada untuk proses pengetesan.
Misalkan kita membutuhkan satu tambahan method pada kelas abstrak MachineController, yaitu
method overflow(). Maka kita akan membuat sebuah kelas baru, kelas abstrak TestController, yang
diturunkan dari kelas MachineController.
Sebagai kelas abstark, TestController membutuhkan StarPressController dan ShellController untuk
mendefinisikan method abstrak getQueueMax(). Maka bentuk diagram kelas yang kita miliki sekarang
adalah :
Dengan penambahan suatu mekanisme baru, maka bertambahlah tiga buah kelas pada diagram kelas kita.
Bagaimana nanti jika kita akan menambahkan dua mekanisme baru? Berarti akan ada penambahan enam
kelas baru! Bagaimana jika ada sepuluh mekanisme baru?! Begitu seterusnya hingga kelas-kelas ini
beranak-pinak.

Keruwetan ini dapat ditangani oleh bridge pattern.

Langkah yang perlu dilakukan adalah :

1. Buatlah sebuah interface yang berisi method-method abstrak dari superclass (MachineController).
2. Untuk kelas-kelas yang mendefinisikan method abstrak dengan definisi yang
berbeda, pindahkan letakkan dibawah interface. (implements)
3. Kelas abstrak MachineController didefinisikan sebagai concrete class .
4. Lakukan aggregasi! Buatlah sebuah atribut yang merupakan instans dari interface
DriverController. Gunakan instans ini untuk mengakses method-method pada interface
DriverController sebagai pengisi dari method konkrit, contohnya inputfull(). [Karena inputfull
membutuhkan method getQueueMax()] Maka “bentuk” method inputfull()sekarang adalah :
public boolean inputfull(){
return driver.getQueueMax() <= driver.getQueue.getSize();
}
Dan diagram kelas kita sekarang adalah :
Nah, sekarang jika kita menginginkan mekanisme kontrol yang baru, tinggal membuat SEBUAH kelas
yang diturunkan dari MachineController, semisal dengan TestController. Demikian pula jika suatu saat
nanti kita membutuhkan tipe driver yang baru, maka kita tinggal menambah sebuah kelas yang
mengimplementasikan DriverController, semisal dengan ShellDriver.

Inilah bridge pattern yang berhasil memisahkan (decouple) antara abstraksi dengan implementasinya.

Dalam bukunya “Design Pattern Explained : A New Perspective on Object-Oriented Design”, Alan
Shalloway dan James R. Trott menyatakan bahwa penurunan memang merupakan “surga” dalam
pemrograman berbasis objek. Namun penggunaan penurunan kelas secara berlebihan akan menyulitkan
pengembangan aplikasi di masa yang akan datang.

Maka sebaiknya kita lebih bijaksana dalam menggunakan penurunan. Mulailah beralih ke aggregasi.
Contohnya seperti yang diimplementasikan dalam bridge pattern dan adapter pattern .
Pertanyaan :

Lalu mengapa pattern ini dinamakan bridge (jembatan) ya?

Referensi :
 Alan Shalloway dan James R. Trott, Design Pattern Explained : A New Perspective on Object-Oriented
Design, 2004, Addison Wesley.
 Steven John Metsker, Design Pattern JAVA Workbook, 2002, Addison Wesley.
 http://www.allapplabs.com/java_design_patterns/bridge_pattern.htm
 http://sourcemaking.com/design_patterns/bridge