Menerapkan Prinsip SOLID di Tongkrongan
Kemaren malem gue lagi ngerjain tugas akhir di warkop deket kampus. Terus ada satu rombongan temen angkatan gue yang dateng, duduk, pesen kopi, dan selama tiga jam full cuma ngeluhin satu topik yang sama: gimana dosen pembimbing mereka itu jahat, ga pengertian, dan selalu revisi bab satu.
Gue yang lagi nyoba fokus nulis kode buat backend sistem pendaftaran pasien, mau ga mau kuping gue panas dengerin mereka muter-muter di problem statement yang itu-itu aja tanpa pernah ngajuin pull request solusi.
Sambil nyeruput kopi hitam gue yang rasanya makin pait, gue iseng mikir. Coba deh bayangin tongkrongan lu itu sebagai sebuah program komputer yang gede. Kalau program lu isinya kelas-kelas atau objek yang fungsinya cuma satu doang (misalnya class TukangNgeluh), sistem lu bakal lambat banget. Ini tuh melanggar prinsip desain software yang paling mendasar: SOLID Principles.
Ayo kita bedah satu-satu.
Pertama, Single Responsibility Principle atau SRP. Prinsip ini bilang kalo setiap class (atau temen) di sistem lu harus punya satu tanggung jawab yang jelas. Kalo ada temen lu yang kerjanya cuma ngeluh terus tiap kumpul, dia itu sebenernya udah menuhin SRP. Tapi masalahnya, value yang dia bawa itu negatif. Tongkrongan yang sehat butuh temen yang punya responsibility seimbang: bisa ngelawak, bisa dengerin curhat, bisa diajak ngerjain tugas bareng. Kalo dia cuma jadi class TukangNgeluh, sistem lu bakal berat nampung error log dia tiap hari. Lu butuh nge-refactor pertemanan lu.
Kedua, Open-Closed Principle atau OCP. Prinsip ini bilang kalo sistem lu harus open for extension, tapi closed for modification. Artinya apa di dunia nyata? Tongkrongan lu harus terbuka buat nerima temen baru (extension), tapi jangan sampe identitas atau nilai dasar dari pertemanan kalian (core module) gampang diubah-ubah sama orang luar. Kalo ada orang baru yang masuk terus tiba-tiba ngatur tempat nongkrong, ngatur jam kumpul, dan ngatur topik obrolan, itu tandanya OCP lu jebol. Pertahanan arsitektur sosial lu lemah banget.
Ketiga, Liskov Substitution Principle atau LSP. Intinya, kalo ada dua objek dari turunan yang sama, mereka harus bisa saling ngegantiin tanpa ngerusak sistem. Di tongkrongan, ini ekuivalen sama orang yang bilang iya iya ntar gue dateng, tapi pas hari H dia ngilang. Dia ngasih janji (interface) kalo dia adalah "TemenNongkrong", tapi behaviour aslinya dia adalah "TemenWacana". Sistem lu langsung crash karena kekurangan orang buat main UNO.
Keempat, Interface Segregation Principle atau ISP. Jangan maksa satu temen buat jadi segalanya buat lu. Kalo lu mau ngomongin startup dan kodingan, cari temen yang emang nerd di bidang itu. Kalo lu mau curhat masalah cinta, cari temen yang empati tinggi. Jangan maksa temen programmer lu dengerin drama percintaan lu, karena itu bukan interface yang dia sediain. Dia bakal error atau ngasih output yang aneh kayak nyuruh lu putusin pacar pake command line.
Kelima, Dependency Inversion Principle atau DIP. Di software, high-level modules ga boleh bergantung sama low-level modules. Di tongkrongan, kebahagiaan lu (high-level) ga boleh bergantung 100 persen sama validasi temen lu (low-level). Kalo lu ngerasa keren cuma pas diajak nongkrong sama circle hits, berarti idup lu terlalu tightly coupled sama mereka. Sekalinya mereka ga ngajak lu main, idup lu langsung throw exception.
Jadi, stop ngeromantisasi pertemanan toxic dengan alasan solidaritas. Solidaritas tanpa prinsip SOLID itu cuma bakal ngasilin spaghetti code di mental health lu.
Bangun sistem pertemanan yang clean, scalable, dan gampang di-maintain. Kalo ada modul yang bikin sistem lambat dan kerjanya cuma throw error doang, ya jangan ragu buat nge-deprecate dia.
- Khay