Pendahuluan

Untuk melihat apa itu Design Pattern, bisa dilihat di sini

Untuk melihat Design Pattern yang diajukan oleh Gang Of Four, bisa dilihat di sini

Sekarang tentang apa ?

Tentang Decorator Pattern

Salah satu Design Pattern yang diusulkan oleh Gang Of Four juga.


Apa itu Decorator Pattern ?

Dari tutorial point :

The decorator pattern is a design pattern that allow to add new functionality to an existing object without altering its structure

Terjemahan bebas :

Decorator Pattern adalah Design Pattern yang memungkinkan untuk menambahkan fungsi secara dinamis ke sebuah objek tertentu, tanpa mengubah struktur dari object tersebut.

Kalau kita contohkan di dunia nyata, maka proses Dekorasi adalah proses untuk memilih, menggabungkan dan menyelesaikan fungsi-fungsi yang dibutuhkan untuk menghias sebuah benda.

Misalkan ketika kita mendekorasi dinding rumah.

Maka yang dilakukan adalah memilih warna cat, melakukan kombinasi warna yang sesuai, memilih pernak-pernik yang akan kita tempelkan diatas dasar dinding rumah.

Begitu pula dengan proses Decorator di Software Engineering.

Design Pattern ini berfungsi sebagai “Penghias” dari sebuah objek yang sudah ada.

Dengan adanya Decorator Pattern ini, maka kita bisa menambah hiasan diatas object yang lain dan membentuk sebuah hasil yang indah.

Dinding rumah, bisa kita menghiasnya dengan cat menggunakan cat air atau cat minyak, atau menggunakan perekat wallpaper.

Cat nya bisa berupa cat polos, berpola, pakai cetakan, atau pun dengan gradasi warna.

Ketika catnya selesai, maka kita juga bisa menambahkan pernak-pernik di atasnya, seperti wallpaper baru, atau pigura foto, ataupun tulisan-tulisan art deco khusus di bagian tertentu di dinding kita.

Dan bukan cuma itu, pernak-pernik diatasnya tadi bisa kita ganti-ganti lagi sesuka kita setelah sebulan, setahun, atau seminggu dengan pernak-pernik yang kita sukai tanpa harus menghancurkan catnya terlebih dahulu.

Ketika kita melihat hasil dari dinding yang kita dekorasi, maka kita akan melihat sebuah dinding yang indah dan bagus, yang merupakan kombinasi dari banyak hiasan komponen diatas.

Dan pada akhirnya kita melihatnya sebagai sebuah struktur baru yang bagus, tidak hanya sebagai dinding polos saja.

Walaupun ditambahkan sebagai penghias saja, tetapi dari sisi kita melihatnya sebagai struktur dinding dengan pernak-pernik dan tambahan objek diatasnya yang bertumpuk-tumpuk.

Oleh karenanya, maka Decorator Pattern ini termasuk ke dalam Struktural Design Pattern di kategori Design Pattern GoF.


Jadi, apa persoalan utama yang diselesaikan oleh Decorator Pattern ini ?

Persoalan utama yang diselesaikan oleh Decorator Pattern ini adalah :

Kebutuhan untuk menambahkan banyak fungsi atau behaviour tertentu secara dinamis terhadap sebuah objek di saat Runtime, tentunya dengan cara yang elegan.

Hmm.., maksudnya seperti apa ? Apa perlunya menambahkan fungsi atau behaviour di saat runtime ?

Kenapa tidak cukup dengan menambahkan di saat compile time saja ?

Ok..ok, kita coba bahas satu-satu


1. Menambahkan fungsi/behaviour di struktur codenya langsung sehingga bisa divalidasi di waktu compile time

Ini adalah pendekatan alami dan pertama yang biasanya akan kita lakukan ketika menemui persoalan diatas.

Pendekatan ini artinya behaviour atau fungsi yang kita tambahkan itu benar-benar kita jadikan sebagai fungsi atau behaviour baru di code kita, memakai pendekatan inheritance.

Istilahnya kita benar-benar membuat sebuah template/class baru setiap kali kita membutuhkan tambahan fungsi/behaviour baru.

Pemisalan yang mudah misalnya dengan sebuah object rumah.

Ketika kita membutuhkan rumah dengan tipe minimalis, modern, atau classic, maka kita akan membuat 3 class sebagai template :

  • RumahMinimalis extends Rumah
  • RumahModern extends Rumah
  • RumahClassic extends Rumah

Ok, fine…

Tetapi bagaimana ternyata nanti ada tipe rumah yang mempunyai tambahan fungsi atu behaviour tipe rangka hollow, kayu, atau alumunium di masing-masing rumah tersebut.

Hmm, dengan pendekatan ini, maka kita akan bikin tambahan class baru lagi seperti berikut :

  • RumahMinimalisHollow extends RumahMinimalis
  • RumahMinimalisKayu extends RumahMinimalis
  • RumahMinimalisAlumunium extends RumahMinimalis
  • RumahModernHollow extends RumahModern
  • RumahModernKayu extends RumahModern
  • RumahModernAlumunium extends RumahModern
  • RumahClassicHollow extends RumahClassic
  • RumahClassicKayu extends RumahClassic
  • RumahClassicAlumunium extends RumahClassic

Hmm..terlalu boros class dan akan membingungkan sekali bagi Software Engineer yang melihat code ini setelahnya.

Ok..ok.., bagaimana kalau kita taruh property Hollow, Kayu, atau Alumunium di 3 class awal tadi, agar tidak usah membuat begitu banyak class..

Bisa jadi., dan boleh dicoba..

Coba kita lihat, class utamanya tetap ada 3 :

  • RumahMinimalis extends Rumah
  • RumahModern extends Rumah
  • RumahClassic extends Rumah

Dan ditiap class akan ada 1 property yaitu :

  • TipeRangka, bertipe enum, yang nilainya bisa Hollow, Kayu, atau Alumunium.

Voilaaa.., solved dengan bagusnya.

Cukup dengan satu property, maka kita bisa set tipe rumah dengan mudahnya.

Tidak perlu membuat banyak template class seperti diatas.

Tapi tunggu..Rumah Classic tidak akan menggunakan rangka Hollow, dan Rumah Modern juga tidak menggunakan rangka kayu.

Hmm, berarti kita mengalami kesulitan dalam memetakan mana yang boleh pakai Hollow, Kayu, atau Alumunium.

Memasukkannya sebagai atribut/behaviour dari sebuah objek akan membuat constraint yang aneh di objeknya itu sendiri.

Kita tentunya harus memastikan bahwa ketika kita menginstantiate RumahModern, maka tipe rangkanya tidak boleh pakai kayu, dst.

Banyak sekali kombinasi yang lain juga selain dari tipe rangka, misalnya Rumah dengan Taman atau tidak, dll.

Terutama untuk behaviour sebuah objek

Kalau behaviour atau fungsi yang kita tambahkan itu cuma satu saja, maka tidak perlu design pattern ini.

Tetapi pada kenyataannya, behaviour atau fungsi tambahan yang kita tambahkan bisa saja banyak dan bertambah seiring waktu, seiring pertambahan requirement aplikasi.

Pemisalan untuk Rumah diatas, misalnya ada kebutuhan Rumah dengan Taman, Rumah dengan kolam Renang, dll.

Secara natural, paling mudah menyelesaikannya adalah dengan menambahkan attribute baru di class-class diatas.

Tetapi hal ini akan melanggar konsep O (Open Close Principle) di konsep SOLID nya OOP.

Coba kita lihat lagi prinsip Open Close Principle :

Open Close Principle –> Open for Extension, Closed for Modification

Jadi ketika kita bisa berulang kali melakukan modifikasi terhadap class yang sudah ada, maka artinya kita melanggar prinsip Closed for Modification.

Dan membuat code kita tidak elegan lagi, apalagi ternyata behaviour yang ditambahkan misalnya hanya berlaku bagi sebagian kecil kasus.

Ketika kasus itu terjadi, maka secara beruntutan akan melanggar prinsip L (Liskov Subtitution Principle) di konsep SOLID nya OOP.

Apalagi kemudian ketika yang kita tambahkan banyak fungsi lain, seperti fungsi menambahkan kanopi di garasi rumah, yang hanya bisa dilakukan di jenis rumah tertentu.

Akibatnya ukurang class kita membengkak, dan menangani banyak hal sekaligus.

Hal ini akhirnya membuat class kita melanggar S (Single Object Responsibility) dari prinsip SOLID.

Oleh karena itu kita harus menemukan cara agar solusinya lebih sederhana, elegan, dan tentunya tidak melanggar konsep SOLID nya OOP.

Kita bahas di artikel selanjutnya yaa. Part 2