SOLID adalah lima prinsip desain berorientasi objek yang membantu kita menulis kode yang lebih mudah dipahami, diuji, dan dikembangkan seiring waktu. Prinsip ini pertama kali dipopulerkan oleh Robert C. Martin (Uncle Bob) dan sampai sekarang masih jadi acuan dasar banyak developer, apa pun bahasa atau frameworknya. Kelima huruf dalam SOLID masing-masing mewakili satu prinsip:

• S — Single Responsibility Principle
• O — Open/Closed Principle
• L — Liskov Substitution Principle
• I — Interface Segregation Principle
• D — Dependency Inversion Principle

Single Responsibility Principle (SRP)

Sebuah class atau modul sebaiknya hanya punya satu alasan untuk berubah — artinya hanya bertanggung jawab atas satu hal saja. Kalau sebuah class melakukan terlalu banyak pekerjaan, perubahan kecil di satu tanggung jawab bisa berisiko merusak tanggung jawab lain yang sebenarnya tidak berhubungan.

Open/Closed Principle (OCP)

Kode harus terbuka untuk ekstensi, tapi tertutup untuk modifikasi. Saat ada kebutuhan baru, idealnya kita menambah kode baru (misalnya lewat interface atau inheritance), bukan mengubah kode lama yang sudah teruji dan dipakai di banyak tempat.

Liskov Substitution Principle (LSP)

Subclass harus bisa menggantikan parent class-nya tanpa mengubah perilaku program yang sudah benar. Kalau kode yang memakai parent class jadi rusak ketika parent-nya diganti dengan subclass, berarti hierarki class tersebut melanggar LSP.

Interface Segregation Principle (ISP)

Lebih baik punya banyak interface kecil yang spesifik daripada satu interface besar yang memaksa semua implementasinya punya method yang belum tentu mereka butuhkan.

Dependency Inversion Principle (DIP)

Modul level tinggi tidak boleh bergantung langsung pada modul level rendah — keduanya harus bergantung pada abstraksi (interface). Prinsip ini yang mendasari pola seperti dependency injection, dan membuat kode jauh lebih mudah diuji karena dependency-nya bisa di-mock.

Kapan SOLID sebaiknya dipakai?

SOLID bukan aturan yang harus dipaksakan di setiap baris kode. Untuk script kecil atau prototipe, menerapkan semua prinsip ini secara ketat justru bisa menghasilkan abstraksi berlebihan yang tidak perlu. SOLID paling terasa manfaatnya di kode yang:

• Akan dipakai dan dimodifikasi dalam jangka panjang oleh banyak orang
• Punya banyak dependency eksternal (database, API pihak ketiga, dll.) yang perlu di-mock saat testing
• Sering mendapat requirement baru tanpa boleh mengubah behavior yang sudah ada

Intinya, gunakan SOLID sebagai panduan untuk mengenali kapan kode mulai sulit diubah atau diuji — bukan sebagai checklist yang harus dicentang semua di setiap fungsi yang kita tulis.