![Seberapa Penting Design Pattern dan Programming Principle](https://images.ctfassets.net/7wjlcr9d5ii8/6i8d0XsJ5LoAzicz7r6a80/2e4cb4164229d7c1d2e012688a01e859/explains.png?w=1024&h=768&q=100&fm=png&fit=thumb&f=faces)
Design Pattern dan Programming Principle adalah teori yang sudah teruji untuk menyelesaikan permasalahan-permasalahan yang umum ditemukan saat melakukan coding. Sebelumnya gw udah membahas beberapa design pattern yang pernah gw pakai. Kali ini gw akan bahas seberapa penting design pattern tersebut digunakan. Mungkin banyak juga yang bingung, kenapa harus pakai design pattern, kenapa ga dibebasin aja sesuka hati. Berikut adalah beberapa point of view gw terhadap design pattern dan programming principle:
Programming itu 90% membaca Code, dan hanya 10% menulis Code
Anonymous
Junior programmer itu biasanya mengikuti kodingan yang sudah ada sebelumnya. Jika codingan sebelumnya udah berantakan dari awal, si junior akan membuatnya lebih berantakan lagi. Jika dari awal codingannya udah bersih, si junior akan ter-guide dengan sendirinya membuat pola yang sama. Misalkan sebuah program dikerjakan oleh Budi menggunakan pendekatan 'kumaha aing pattern' yang ia ciptakan sesuka hati. Lalu program tersebut dilanjutkan oleh Yustisio dengan pendekatan 'sak karepe dewe pattern' yang juga ia karang-karang sendiri. Ketika mereka resign, program tersebut dilanjutkan oleh anak baru, yaitu Ani. Ani tidak tahu 'kumaha aing pattern' & 'sak karepe dewe pattern' yang digunakan Budi & Yustisio. Tentu hal itu sangat membuat Ani menderita, depresi, dan ingin bunuh diri. Ia harus mempelajari pattern siluman yang diciptakan Budi & Yustisio yang ga jelas asal-usulnya, banyak celah, dan sama sekali tidak teruji. Yang ada malah si Ani juga akan membuat pattern dia sendiri sesuka hati yang rentan terhadap bugs, dan membuat code tersebut semakin berantakan. Bandingkan jika Budi dan Yustisio menggunakan Design Pattern yang benar yang sudah teruji, dikenal dan diterapkan orang banyak, tentu si Ani akan lebih mudah mempelajari codingannya sekalipun si Budi dan si Yustisio ini sudah resign. Ani pun akan ter-guide dengan sendirinya mengikuti code yang udah rapi.
Kemampuan sebuah program untuk bisa survive terhadap perubahan merupakan bentuk suatu kematangan aplikasi yang dibuat. Yang namanya perubahan itu adalah hal pasti dalam teknologi. Dulu requirementnya begini, sekarang begitu, dan di masa yang akan datang juga bakal beda lagi. Design pattern dan programming principle adalah hal yang membantu kematangan tersebut. Jadi ketika ada perubahan requirement, kita dapat meminimalisir terjadinya breaking changes. Contohnya ketika suatu program dependent terhadap implementation class, program tersebut akan sulit dimodifikasi. Akan tetapi bila program tersebut dependent terhadap interface (Programming to Interface, Open-Close Principle, Strategy Design Pattern), ketika melakukan perubahan kita tidak perlu mengubah program secara keseluruhan, tapi hanya implementation class saja. Atau ketika menggunakan inheritance hanya untuk melakukan sharing code. Subclass akan 'terpaksa' mewarisi semua function atau variable dari superclass, meskipun ada code turunan yang belum tentu sesuai dengan kebutuhan subclass. Code tersebut jadi sulit dimodifikasi. Akan lebih baik jika hal itu diganti dengan composition (Composition over Inheritance Principle) dimana sebuah class tidak terkekang oleh superclass dan sharing code dilakukan lewat composition sehingga kita menggunakan function dari composition tersebut seperlunya saja. Dan masih banyak lagi contoh konkretnya.
Design pattern dan programming principle yang digunakan sekarang itu sebagian besar sudah digunakan dari tahun 80an dan 90an. Walaupun diciptakan sejak puluhan tahun yang lalu, teori-teori tersebut masih relevan hingga sekarang karena sangat general dan tidak terikat untuk satu bahasa saja. Beberapa hal yang lagi nge-trend di zaman sekarang pun semuanya berasal dari teori-teori yang sudah ada dari tahun 80an, seperti Functional Programming, Object Oriented Programming, Liskov Substition pada SOLID Principle, Law of Demeter, Composition over Inheritance, dan beberapa lainnya. Design pattern yang ditulis dari tahun 90an juga masih relevan untuk beberapa bahasa pemrograman dan menjadi standard indsutri di beberapa perusahaan di masa sekarang. Ga hanya itu, beberapa teori seperti Remote Call Procedure, Test Driven Development, dan Microservices juga udah ada lebih dari sepuluh tahun yang lalu tapi mulai nge-trend lagi sekarang. Ga ada yang namanya 'kuno' atau 'udah basi' selama itu bisa menjadi problem solver terbaik terhadap permasalahan yang dihadapi.
Best Practice setiap paradigma pemrograman itu berbeda-beda antara satu dengan lainnya. Jangan dicampur-adukkan karena belum tentu cocok. Contohnya ketika menggunakan functional programming, tentu saja Design Pattern pada Object Oriented Programming tidak berlaku di sana. Mencampur adukkan design pattern dan principle antar paradigma bisa menimbulkan kekacauan. Programming principle dan Design Pattern OOP cocok untuk bahasa yang menggunakan paradigma OOP murni seperti Java, Typescript, C#, dan sejenisnya. Functional programming juga memiliki design pattern dan principlenya masing-masing. Untuk bahasa prototype object seperti Javascript atau Go yang tidak sepenuhya OOP, juga tidak semua design pattern OOP cocok di sana, hanya beberapa ptinciple saja. Memang ada beberapa principle yang bisa diterapkan antar paradigma, tapi ga semuanya. Gunakan sesuai best practice masing-masing.
Setiap jawaban dari best practice itu selalu diawali dengan kata 'it depends' (tergantung kondisi). Tidak ada yang namanya silver bullet, satu solusi untuk semua masalah. Tidak semua kasus bisa diselesaikan dengan satu metode saja. Design Pattern dan Programming Principle pun sama, itu bukan undang-undang yang kaku, yang harus banget seperti itu. Keduanya hanyalah guide yang akan memandu kita dan maintainers setelah kita agar coding lebih terstruktur dan konsisten. Semuanya kembali lagi tergantung kondisi permasalahan yang dialami. Itulah gunanya kemampuan analisa, itu sangat penting ketika menjadi software engineer. Kita harus tahu pertimbangan-pertimbangannya, pro-kontra, kapan harus begini, kapan harus begitu, semuanya ditempatkan sesuai porsinya masing-masing.