Apa itu design Pattern ?

Apakah sebuah framework, seperti Spring, Angular ? Tidak
Apakah sebuah library aplikasi, seperti Apache Common, React ? Tidak
Apakah sebuah tools, seperti Eclipse, JMeter ? Tidak
Apakah sebuah dependency management, seperti maven, npm, gradle ? Tidak
Apakah sebuah service mesh, seperti kubernetes, istio, linkerd ? Tidak
Apakah sebuah algoritma ? bukan..
Apakah sebuah desain ? bisa jadi..
Apakah sebuah solusi ? bisa jadi..

Jadi apa sebenarnya Design Pattern ini ?

Design Pattern adalah kerangka desain solusi umum untuk permasalahan rumit yang sering ditemui di sebuah aplikasi.

Sejauh mana dianggap sebagai desain ?

Design Pattern berada di level software design, jadi isinya berupa desain “komponen” aplikasi, dan desain logika di high level.

Sejauh mana dianggap sebagai permasalahan rumit ?

Rumit nya sebuah logik aplikasi memang relatif. Rumitnya itu bisa saja tergantung dari banyak kasus logik nya, besarnya aplikasi yang dibuat, derajat criticalnya aplikasi, tingkat banyaknya komponen yang terlibat, dll.

Permasalahan rumit dalam kategori ini adalah untuk kategori permasalahan spesifik yang berulang, sering terjadi, dan diketahui oleh banyak orang dalam membuat aplikasi.

Contoh :

  1. Aplikasi yang membuat laporan dengan format yang sama, dengan template laporan yang seragam, tetapi dengan isi yang berbeda tergantung jenis laporannya. Permasalahan ini banyak terjadi di aplikasi tipe apapun, tetapi spesifik terhadap kasus laporan dengan format yang sama. Apakah cukup rumit ? bisa jadi.
  2. Aplikasi yang mempunyai banyak tipe objek yang hampir sama tetapi berbeda dalam beberapa hal spesifik, yang harus dipakai di waktu dibutuhkan dan baru diketahui pada saat runtime saja.
  3. Aplikasi yang melakukan integrasi dengan aplikasi lain. Permasalahan yang spesifik untuk integrasi.
  4. Aplikasi yang mempunyai objek terdiri dari banyak attribut.
  5. Aplikasi yang membutuhkan fasilitas untuk undo/rollback.
  6. Aplikasi yang membutuhkan pemisahan antara tampilan, data, dan flow bisnisnya..
  7. dll.

Kelihatannya seperti biasa saja kan ? Ini bisa diselesaikan dengan cara apapun kan ? Dengan algoritma dasar yang kita ketahui, kita akan bisa mencapai tujuan aplikasi yang kita sebutkan diatas.

Dengan menggunakan struktur algoritma If…then…else , case…when, maka aplikasinya akan jalan juga kan ?

Lalu ?

Betul sekali, dengan memakai konsep If…then…else, case…when , maka tujuan dari aplikasi tersebut tetap akan tercapai.

Tetapi ada kekurangannya :

  1. Kita akan punya solusi sangat spesifik baik desain dan algoritmanya terhadap kasus tersebut.
  2. Kalau terjadi perubahan di logic code nya, maka kita mesti melihat code nya secara lebih dalam dan mesti “menghapal” logic codenya, karena terdiri dari banyak percabangan.
  3. Kita akan masuk terlalu detail ketika menjelaskan kepada orang lain (biasanya orang IT Aplikasi atau Orang bisnis yang mengerti sedikit IT) mengenai program kita. Kita tidak akan bisa menjelaskan dengan level yang lebih abstrak.
  4. Bisa saja bagian tertentu dari aplikasi kita tidak reusable dan tidak bisa digunakan untuk kasus yang lain yang semirip. Kita akan melakukan copy paste code untuk kasus yang serupa.
  5. Code kita akan sulit dikelola dan ditambahkan fiturnya ketika ada kebutuhan baru dan logic baru.
  6. Code kita tidak elegan dari sisi desain aplikasi dan desain arsitektur.

Trus..mana Design Pattern nya ?

Oke..oke, sabar…sabar.

Mari kita lanjut ceritanya dahulu.

Awalnya kita akan melakukan proses diatas. If…then…else, case..when, dll.

Namun lama kelamaan kita akan mendapatkan banyak kasus/requirement baru, berupa logic bisnis atau logic teknis yang serupa di aplikasi yang kita punyai.

Banyak case baru yang mesti kita tangani dengan logic kita yang lama. Ternyata logic kita yang lama tidak mampu lagi untuk menangani case yang baru. Berapa banyak if…then…else , case…when yang akan kita tambahkan agar logic kita yang lama tetap berjalan. Apalagi didalamnya ada kasus spesifik dan percabangan yang banyak. Bisa jadi kasus if…else..then, when…case yang dibutuhkan sebanyak kombinasi atau bahkan permutasi dari jumlah kasusnya. Sehingga jadilah program kita yang sederhana menjadi program yang rumit.

Sehingga akhirnya kita berpikir, saya mesti desain ulang program yang sekarang dengan elegan agar bisa menangani kasus ini dan kasus lain yang serupa yang mungkin saja datang belakangan, sehingga saya mudah mengubah, memahami, dan memperbaiki logik nya nanti.

Inilah yang kemudian mendasari kemunculan Design Pattern.

Contoh Design Pattern :

  1. Template Method Pattern, misalnya untuk kebutuhan membuat laporan/report PFD yang banyak, punya template yang hampir sama, tetapi isinya bisa berbeda dan logik nya berbeda tergantung tipe laporannya.
  2. Builder Pattern , misalnya untuk membuat objek yang kompleks dan mempunyai banyak attribut. Bisa jadi attribute nya itu akan bertambah pula di coding selanjutnya.
  3. Memento Design Pattern, misalnya untuk kasus kita butuh melakukan rollback terhadap sebuah flow/aksi di logik kita.

Design Pattern diatas dibuat dengan cara yang sedemikian sehingga logiknya mudah nantinya untuk dimodifikasi, ditambah atau dikurangi.

Jadi …

Design Pattern adalah kerangka desain solusi umum yang elegan, dirancang untuk menyelesaikan satu permasalahan rumit yang spesifik terhadap kasus tertentu yang sering terjadi di sebuah aplikasi.

Sejauh mana dianggap elegan ?

Elegan pun bisa dianggap relatif. Elegan artinya membuat sebuah kasus yang rumit menjadi sederhana dan efektif dengan cara yang tidak biasa.

Dengan kata lain , dalam desain aplikasi, Elegan adalah solusi dengan tingkat kompleksitas yang rendah, untuk kasus problem dengan kompleksitas tinggi.

Design Pattern dalam hal ini, mencoba membuat solusi elegan untuk kasus problem dengan kompleksitas tinggi. Hal inilah yang membuat kenapa Design Pattern menjadi terkenal dan banyak digunakan.

Sedalam apa solusinya ini dibandingkan solusi lain ?

Solusi yang ditawarkan oleh Design Pattern ini adalah kerangka desain solusi umum terhadap kasus spesifik di high level aplikasi.

Ini yang membedakannya dengan solusi algoritmik yang berada di low level, seperti divide and conquer design, teknik greedy , atau memoization di dynamic programming.

Ini juga yang membedakannya dengan konsep SOLID, DRY, GRASP, dll yang merupakan solusi abstrak yang terlalu umum untuk kasus umum, sehingga bisa masuk ke level Principle.

Kalau begitu, semua orang bisa bikin design patternnya sendiri ?

Untuk bisa disebut sebagai Design Pattern, maka minimal harus memenuhi persyaratan khusus, diantaranya solusi yang kita buat tersebut mesti diakui, dikenal, dan digunakan oleh kebanyakan Software Engineer, mesti merupakan desain solusi umum terhadap kasus spesifik yang sering ditemui.

Sehingga pengakuan terhadap sebuah Design Pattern ini lebih kepada konsensus, kesepakatan, dan sosialisasi Design Pattern itu sendiri, agar banyak Software Engineer yang menggunakannya. Lambat laun Design Pattern yang diperkenalkan itu menjadi Design Pattern yang dikenali.

Saat ini , Design Pattern yang diperkenalkan oleh Gang Of Four sebanyak 23 design pattern menjadi acuan utama dari kebanyakan Software Engineer di dunia. Walaupun banyak juga design pattern lain yang diperkenalkan oleh ahli-ahli di bidang aplikasi IT.

Implementasi dari design pattern nya sendiri tergantung dari yang melakukan implementasinya. Akan tetapi konsep solusi Design Pattern nya itu sendiri harus merupakan solusi umum yang elegan, terbukti sepanjang waktu, dan diakui oleh kebanyakan Software Engineer.