Mengenal Prinsip SOLID Secara Singkat
Pernah nggak sih, kamu nulis kode yang awalnya rapi, tapi lama-lama jadi berantakan? Fitur baru ditambah, kode makin panjang, dan akhirnya malas buat nyentuh file itu lagi. Tenang, kamu nggak sendirian. Di sinilah prinsip SOLID bisa jadi penyelamat.
SOLID sebenarnya adalah singkatan dari lima prinsip desain dalam pemrograman berorientasi objek. Diciptakan oleh Robert C. Martin (Uncle Bob), prinsip ini membantu kita menulis kode yang lebih rapi, mudah dirawat, dan fleksibel untuk perubahan. Yuk, kenalan satu per satu.
—
S – Single Responsibility Principle (SRP)
Satu kelas, satu tanggung jawab.
Bayangin kamu punya pisau dapur yang juga bisa jadi obeng, gunting, dan pembuka botol. Repot, kan? Sama halnya dengan kode. Sebuah kelas sebaiknya hanya punya satu alasan untuk berubah. Kalau kelasmu ngurusin laporan, menyimpan data, dan ngirim email sekaligus, saat ada perubahan cara ngirim email, kamu harus ubah kelas itu – padahal mungkin bagian laporan dan penyimpanan baik-baik aja.
Intinya: pisahkan tugas. Buat kelas khusus untuk masing-masing tanggung jawab.
—
O – Open/Closed Principle (OCP)
Terbuka untuk ekstensi, tertutup untuk modifikasi.
Artinya, kita harus bisa menambah fitur baru tanpa mengubah kode yang sudah ada. Misalnya, kamu punya kelas `HitungDiskon`. Kalau mau nambah jenis diskon baru, kamu seharusnya nggak perlu mengutak-atik kelas itu. Cukup buat kelas baru yang mewarisi atau mengimplementasikan interface yang sama.
Caranya? Manfaatkan inheritance atau interface. Dengan begitu, kode lama tetap aman, dan kita cuma perlu nambahin kode baru.
—
L – Liskov Substitution Principle (LSP)
Objek dari kelas turunan harus bisa menggantikan objek dari kelas induk tanpa mengubah perilaku program.
Kedengarannya teknis, tapi sederhana: kalau punya fungsi yang pakai parameter `Hewan`, kamu harus bisa ngirim `Kucing` atau `Anjing` tanpa error atau hasil yang aneh. Contoh pelanggaran klasik: kelas `Persegi` yang diturunkan dari `PersegiPanjang`. Kalau kamu set lebar dan tinggi di `Persegi` secara terpisah, jadinya nggak konsisten karena persegi punya ukuran sisi yang sama.
Aturan mainnya: pastikan turunanmu benar-benar “adalah” tipe dari induknya, bukan sekadar mirip.
—
I – Interface Segregation Principle (ISP)
Buat interface yang spesifik, jangan terlalu umum.
Lebih baik punya banyak interface kecil daripada satu interface besar yang memaksa kelas mengimplementasikan method yang nggak dipakai. Contoh: interface `Pekerja` punya method `makan()`, `tidur()`, dan `coding()`. Tapi robot juga pekerja, dan robot nggak makan atau tidur. Alhasil, robot harus implementasi method kosong atau lempar exception.
Solusinya: pecah jadi `PekerjaManusia` dan `PekerjaRobot`, atau interface yang lebih spesifik seperti `DapatMakan`, `DapatTidur`, `DapatCoding`. Kelas bisa pilih interface mana yang relevan.
—
D – Dependency Inversion Principle (DIP)
Bergantung pada abstraksi, bukan pada implementasi konkret.
Ini soal mengurangi ketergantungan langsung antar modul. Misalnya, kelas `Notifikasi` langsung bergantung pada `EmailSender`. Suatu saat kamu mau ganti jadi `SmsSender`, kamu harus ubah kode `Notifikasi`. Lebih baik `Notifikasi` bergantung pada interface `PengirimPesan`, dan `EmailSender` serta `SmsSender` mengimplementasikannya.
Dengan begitu, kamu bisa ganti-ganti pengirim pesan tanpa menyentuh kelas `Notifikasi`. Semua jadi lebih modular dan mudah diuji.
—
Kenapa Harus Peduli SOLID?
Prinsip SOLID bukan aturan mati, tapi panduan. Dengan menerapkannya, kamu akan:
– Kode lebih mudah dibaca – karena setiap bagian punya peran jelas.
– Mudah diuji – ketergantungan antar modul berkurang, testing jadi simpel.
– Mudah dikembangkan – nambah fitur tanpa takut merusak yang sudah jalan.
– Kolaborasi tim lebih lancar – struktur kode yang konsisten bikin anggota tim saling ngerti.
Nggak perlu langsung sempurna. Mulailah dari satu prinsip, misalnya SRP, lalu perlahan biasakan. Seiring waktu, kamu akan merasakan bedanya: kode yang dulu bikin pusing, kini lebih bersahabat. Selamat mencoba!