Strategy Pattern (Bagian 1)

Pattern pertama yang dipost-kan dalam blog ini bernama Strategy Pattern. Pattern ini juga yang pertama kali didemonstrasikan pada buku Head First Design Pattern. Pada postingan kali ini, saya ingin menceritakan kembali ilustrasi yang diberikan pada buku tersebut. Senang rasanya membaca buku yang sangat menarik dan unik ini. Selain mendapat pencerahan tentang design pattern, buku ini juga dipenuhi gambar-gambar ilustrasi. Bahkan tulisan-tulisan cuma mendapat porsi yang lebih sedikit dibanding gambar ilustrasinya. But it works anyway, at least for me. Saya menjadi tahu apa itu design pattern. 

Simulasi bebek-bebek mungil

Ceritanya, ada seorang programmer OO bernama Joe yang bekerja di suatu software company. Perusahaan tersebut membuat game simulasi bebek-bebek di kolam, yang diberi nama SimUDuck. SimUDuck dapat menunjukkan berbagai spesies bebek yang berenang dan membuat suara kwek-kwek. Game ini pada mulanya dibuat dengan teknik Object-Oriented dan menggunakan superclass Duck sehingga dapat di-inherit oleh semua tipe bebek.

Desain Awal SimUDuck

Karena adanya game saingan dari kompetitor, perusahaan ini ingin mengembangkan SimUDuck dengan tambahan fitur yang lebih menarik. Mereka ingin membuat bebek-bebek tersebut bisa terbang. Dengan begitu, mereka dapat mengalahkan kompetitor mereka. Dan Joe, sebagai programmer perusahaan, diberikan tugas mem-program requirement tersebut. Joe merasa tidak ada yang susah, karena dia berpikir tinggal menambahkan method fly() ke class Duck, dan Done! 

Joe menambahkan method fly() pada superclass Duck

Saat demonstrasi program, tiba-tiba sesuatu yang buruk terjadi. Bebek-bebek karet (rubber duckies) beterbangan kemana-mana di layar! Apakah ini lelucon? Rubber duckies harusnya tidak dapat terbang. Joe lupa bahwa tidak semua bebek bisa terbang. Ketika Joe menambahkan behaviour baru pada superclass Duck, ia juga menambahkan behaviour yang tidak cocok dengan beberapa subclass dari Duck. Jadi, update yang localized pada kode malah menyebabkan efek samping yang tidak lokal (misal. bebek-bebek karet yang bisa terbang).

Rubber duckie dapat terbang!

f

INHERITANCE (Bukan solusi yang bagus untuk kasus ini)

Joe berpikir dengan inheritance bisa memecahkan kasus penambahan requirement terbang ini. Ia dapat meng-override method fly() pada rubber duck. Ia tinggal membiarkan kosong method fly() pada rubber duck. Hal ini sama seperti cara ia meng-override method quack(). Tetapi apa yang akan terjadi ketika akan menambahkan bebek kayu (wooden duck) pada program? Mereka tidak seharusnya bisa terbang dan juga bersuara kwek (quack). Joe sadar inheritance mungkin bukan jawabannya, karena produk ini terus-menerus diupdate. Joe tahu spec akan terus berubah, artinya ia harus terus memeriksa dan kemungkinan meng-override fly() dan quack() untuk tiap subclass baru dari Duck. Joe butuh cara yang lebih efektif yang memungkinkan ia mempunyai beberapa bebek (tidak semua) yang dapat terbang dan berkwek.

f

INTERFACE (Still, bukan solusinya)

Joe kemudian berpikir ke interface. Ia dapat mengeluarkan fly() dari superclass Duck dan membuat interface Flyable() dengan method fly(). Dengan begitu, hanya bebek yang bisa terbang yang akan mengimplementasikan interface ini dengan mempunyai method fly(). Begitu juga dengan quack(), ia dapat membuat interface Quackable, karena tidak semua bebek dapat bersuara kwek. Tapi coba pikir tentang duplikasi kode? Dengan interface, Joe harus menuliskan method fly() di semua subclass yang mengimplementasikan interface Flyable(). Bagaimana kalau terjadi perubahan pada method fly()? What a Pain!

Masih harus mengimplementasikan fly() satu-per-satu

Kalau saja ada cara untuk mengembangkan software sehingga jika kita perlu mengubahnya, kita dapat melakukannya dengan efek yang terkecil pada kode yang sudah ada? Kalau saja ada, kita hanya perlu waktu sebentar untuk merevisi kode dan membuat software yang lebih keren?

Ok, solusinya ada di postingan berikutnya pada Strategy Pattern (Bagian 2). Stay tuned ……..