Memahami Prinsip SOLID: Ilmu Wajib untuk Naik Level Jadi Senior Developer

Kode yang Berjalan Belum Tentu Kode yang Baik

Saat melamar kerja di level *Mid* atau *Senior Developer*, wawancaramu tidak lagi seputar "Cara menggunakan if-else". Wawancaramu akan berpusat pada Software Architecture. Salah satu teori paling legendaris yang harus kamu kuasai adalah Prinsip S.O.L.I.D.

Prinsip ini dicetuskan oleh "Uncle Bob" (Robert C. Martin) untuk membantu *programmer* membuat kode berbasis OOP (Object-Oriented Programming) yang rapi, tidak rapuh, dan gampang dikembangkan.

Bedah 5 Huruf S.O.L.I.D

1. S - Single Responsibility Principle (Satu Tanggung Jawab)

"Sebuah Class atau Fungsi hanya boleh punya SATU alasan untuk diubah."
Artinya: Jangan membuat fungsi raksasa bernama "Robot Super" yang mengurus koneksi Database, sekaligus mengirim Email, sekaligus mencetak Struk HTML. Pisahkan ketiganya! Buat FungsiDatabase, FungsiEmail, dan FungsiCetak. Jika terjadi masalah pada Email, kamu tahu pasti ke file mana kamu harus pergi tanpa takut merusak komponen *Database*.

2. O - Open/Closed Principle (Buka Tutup)

"Kode harus TERBUKA untuk penambahan fitur baru, tapi TERTUTUP untuk dimodifikasi."
Artinya: Jika atasanmu menyuruh menambahkan fitur Pembayaran Gopay (sebelumnya hanya ada Transfer Bank), kamu tidak boleh mengacak-acak kode fungsi *Transfer Bank* yang sudah stabil. Buatlah Kelas/Fungsi Pembayaran baru yang mewarisi antarmuka induk tanpa merusak fungsi yang sudah ada.

3. L - Liskov Substitution Principle (Bisa Saling Tukar)

"Objek dari Class Anak harus bisa menggantikan Objek Class Induk tanpa merusak program."
Artinya: Jika kamu punya *Class* Induk bernama Burung yang memiliki fungsi Terbang(), lalu kamu membuat *Class* Anak bernama Penguin. Karena penguin tidak bisa terbang, memaksakan Penguin mewarisi *Class* Burung akan memicu *error*. Pisahkan desainnya menjadi BurungBisaTerbang dan BurungTidakBisaTerbang.

4. I - Interface Segregation Principle (Pemisahan Kontrak)

"Jangan paksa sebuah Class menggunakan fitur yang tidak dibutuhkannya."
Artinya: Daripada membuat satu Antarmuka (Interface) besar bernama PekerjaPabrik yang memiliki fungsi Makan() dan Kerja(), lebih baik pisahkan menjadi dua. Kenapa? Karena jika kamu membuat *Class* RobotPabrik, robot tidak butuh fungsi Makan()!

5. D - Dependency Inversion Principle (Pembalikan Ketergantungan)

"Modul level tinggi jangan bergantung pada modul level rendah secara langsung."
Artinya: Jangan "menjahit mati" (*Hardcode*) koneksi MySQL langsung di dalam fungsi Laporan Keuanganmu. Gunakan Dependency Injection (menitipkan koneksi melalui parameter). Dengan begitu, jika besok kantormu ganti database ke MongoDB, fungsi Laporan Keuanganmu tidak perlu dirusak, cukup *inject* *Database* yang baru.