Bridge Pattern “Si 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 abstract dan 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