Strategy Pattern (Bagian 2)

Postingan ini merupakan lanjutan postingan sebelumnya pada Strategy Pattern bagian 1. Permasalahan yang dihadapi Joe ternyata tidak dapat diatasi dengan inheritance maupun interface, tetapi dengan, yeah you guess, … design pattern. Untuk menjelaskan bagaimana salah satu design pattern memecahkan masalah ini, kita coba aplikasikan dulu prinsip-prinsip OO design yang baik. 

Sekarang dimulai dengan isu, bahwa CHANGE (huruf besar untuk penekanan) merupakan faktor yang sering terjadi dalam pengembangan software. Tidak peduli bagaimana aplikasi tersebut didesain dengan baik, dalam rentang waktu mendatang, aplikasi harus berkembang dan berubah atau aplikasi tersebut mati.

Jadi, back to story, inheritance yang digunakan Joe ternyata tidak berjalan dengan baik, karena behavior dari duck terus berubah. Behavior tersebut juga tidak cocok dimiliki semua subclass. Setali tiga uang dengan interface. Penggunaan interface Flyable dan Quackable mulanya menjanjikan karena hanya duck yang benar-benar bisa terbang yang mengimplementasikan Flyable. Namun interface tidak memiliki kode implementasi, sehingga tidak bisa reuse. Jika ingin melakukan modifikasi pada behavior, maka kita harus menelusuri semua subclass dimana behavior tersebut didefinisikan untuk kemudian diubah. Tentu bisa memberikan peluang terjadinya bug baru!

Untungnya, terdapat suatu prinsip design untuk situasi ini. 

Prinsip Design:

Identifikasi aspek-aspek pada aplikasi yang berubah dan pisahkan dari yang tetap.

Dengan kata lain, jika terdapat kode yang berubah, misal akibat dari requirement baru, maka behavior ini perlu diambil dan dipisahkan dari semua aspek yang tidak berubah. Istilah lainnya meng-encapsulate yang berubah sehingga kita dapat mengubah atau meng-extend bagian-bagian yang berubah tanpa mempengaruhi yang lain. Konsep ini sebenarnya merupakan dasar dari hampir semua design pattern. Wow!

Sekarang mari kita mengambil behavior dari class Duck. Tapi behavior yang mana? Selain fly() dan quack(), tidak ada bagian dari class Duck yang cenderung berubah. Sehingga class Duck bisa dibiarkan seperti semula dengan sedikit modifikasi. Untuk memisahkan bagian yang berubah dari yang tetap, kita buat dua set kelas, satu untuk fly dan satu untuk quack. Masing-masing set kelas berisi semua implementasi dari behavior fly dan quack. Misalnya satu kelas yang mengimplementasikan quacking, satu kelas lain mengimplementasikan squeaking, dan kelas yang lain yang mengimplementasikan silence. Kelas-kelas ini membentuk satu set kelas yang mengimplementasikan behavior quack. You get the idea. 

Ambil fly() dan quack() dari class Duck

 

MENDESAIN DUCK BEHAVIORS

Sekarang, bagaimana cara kita mengimplementasikan set kelas-kelas ini yang mengimplementasikan behavior fly dan quack?

Tentu desainnya harus fleksibel, karena masalah yang dialami Joe ini bermula dari tidak fleksibelnya behavior duck pada desain awal. Dan kita tahu kita ingin meng-assign behavior kepada instance-instance dari Duck. Misalnya, kita ingin membuat instance MallardDuck yang baru dan menginisialisasinya dengan tipe khusus dari flying behavior. Atau lebih jauh lagi, kita dapat mengganti behavior dari suatu duck secara dinamik. Dengan kata lain, kita memasukkan method yang bertugas sebagai setter behavior sehingga dapat mengubah flying behavior dari MallardDuck saat runtime!

Untuk mencapai hal ini, kita perlu lihat prinsip design yang kedua.

Prinsip Design:

Memprogram dengan interface, bukan dengan implementasi.

Apa maksudnya? 

Kita akan menggunakan interface untuk merepresentasikan masing-masing behavior, misalnya interface FlyBehavior dan QuackBehavior. Dan tiap-tiap implementasi dari behavior akan mengimplementasikan salah satu dari interface ini.

Jadi, kali ini bukan class Duck atau subclassnya yang mengimplementasikan interface FlyBehavior dan QuackBehavior. Melainkan, dua set kelas tadi yang telah dibahas sebelumnya pada bagian encapsulate. Dan dua set kelas ini berupa, sebut saja behavior class, karena alasan dibuat adalah untuk merepresentasikan behavior dengan mengimplementasikan behavior interface.

Cara ini berbeda dengan cara yang digunakan sebelumnya. Cara sebelumnya, behavior-nya berasal dari implementasi konkrit di superclass Duck, atau dari implementasi spesifik di subclass. Kedua kasus tersebut mengandalkan pada implementasi. Kita terkunci oleh implementasi spesifik dan tidak ada ruang, selain me-rewrite code, untuk mengganti behavior.

Dengan desain yang baru, subclass dari Duck akan menggunakan behavior yang direpresentasikan oleh interface (FlyBehavior dan QuackBehavior). Dengan demikian, implementasi konkrit dari behavior tidak akan stuck pada subclass Duck.

      

Interface dari flying behavior

 

Poin dari cara ini adalah ingin memanfaatkan polimorfisme. Artinya tipe variabel yang dideklarasikan harus supertype, biasanya berupa abstract class atau interface, sehingga objek yang di-assign ke variabel tersebut dapat berupa implementasi konkrit dari supertype. Dengan begitu, kelas yang mendeklarasikan variabel ini tidak perlu tahu tipe aktual dari object!

Inilah contoh yang menjelaskan konsep polimorfisme. Bayangkan suatu abstract class Animal dengan dua implementasi konkritnya, Dog dan Cat.

 

Abstract class Animal dengan dua implementasi Dog dan Cat

  

Memprogram dengan implementasi akan seperti:

Dog d = new Dog();

d.bark()

Mendeklarasikan variabel “d” sebagai tipe Dog (implementasi konkrit dari Animal) memaksa kita coding dengan implementasi konkrit.

Tetapi memprogram dengan interface/supertype akan seperti:

Animal animal = new Dog();

animal.makeSound();

Kita tahu objek ini Dog, tetapi sekarang kita dapat menggunakan reference Animal secara polimorfis.

Dan, daripada hard-coding peng-instance-an (seperti, new Dog()), kita dapat meng-assign implementasi konkrit objek saat runtime:

Animal animal = getAnimal();

animal.makeSound();

Kita tidak tahu apa subtype aktual animal. Tetapi, kita tahu bahwa subtype animal ini tahu bagaimana merespon makeSound(). Polimorfisme bekerja!

  

Mengimplementasikan Duck Behaviors

Jadi, kembali lagi ke permasalahan duck behaviors. Kita dapat mempunyai dua interfaces, yaitu FlyBehavior dan QuackBehavior. Masing-masing interfaces tersebut memiliki kelas-kelas yang mengimplementasikan interface ini. Ini dia rancangannya:

Implementasi behaviors Duck

Dengan desain ini, objek lainnya dapat me-reuse behavior fly dan quack karena behavior ini tidak tersembunyi di kelas-kelas Duck. Selain itu, kita dapat menambahkan behavior baru tanpa harus memodifikasi behavior class yang sudah ada atau menyentuh kelas-kelas Duck yang menggunakan behavior ini.

Jadi solusi permasalahan yang dihadapi Joe seperti apa? Kok muter-muter begini.

Ok, sabar. Tadi itu merupakan penjelasan ide yang akan digunakan untuk memecahkan masalah yang dihadapi Joe. Just to make sure there is no such a high leap.

Untuk selanjutnya, kita tinggal mengintegrasikan duck behavior ini ke kelas Duck. Tapi itu untuk postingan selanjutnya di Strategy Pattern bagian 3. Di sana, kita akan mengimplementasikannya sekaligus mengetesnya. Keep stay tuned….