SOLID Principles:

Panduan Lengkap untuk Kode yang Lebih Baik


Lima prinsip desain yang akan mengubah cara kamu menulis kode — dari spaghetti code menjadi arsitektur yang elegan, mudah diuji, dan siap berkembang.


Setiap developer pasti pernah menghadapi kode yang begitu kusut sampai takut untuk menyentuhnya. Ubah satu baris, tiga fitur lain ikut rusak. Tambah satu kelas, semua jadi berantakan. Inilah yang terjadi ketika kode ditulis tanpa prinsip desain yang jelas.


SOLID adalah singkatan dari lima prinsip object-oriented design yang diperkenalkan oleh Robert C. Martin (Uncle Bob). Prinsip-prinsip ini bukan teori abstrak — mereka adalah panduan praktis yang membantu kamu menulis kode yang lebih mudah dipahami, diuji, dan dikembangkan.

Mari kita bedah satu per satu dengan contoh nyata dan analogi yang mudah dipahami.

✦

01 / 05

S — SINGLE RESPONSIBILITY

Single Responsibility Principle
"Sebuah kelas hanya boleh punya satu alasan untuk berubah."


Bayangkan kamu punya seorang karyawan yang harus jadi kasir, chef, sekaligus manajer restoran. Kalau sistem kasir berubah, si karyawan ikut kacau. Kalau menu diupdate, orang yang sama harus turun tangan. Ini tidak efisien dan berisiko tinggi.


Hal yang sama terjadi di kode ketika satu kelas menanggung terlalu banyak tanggung jawab. Daripada membuat satu kelas User raksasa yang mengurus login, profil, dan pengiriman email — pecah menjadi tiga entitas yang fokus:

✦

02 / 05

O — OPEN/CLOSED

Open/Closed Principle
"Terbuka untuk ekstensi, tertutup untuk modifikasi."


Ini prinsip yang paling sering dilanggar saat deadline mendekat. Kamu butuh fitur baru, lalu langsung buka kelas yang sudah berjalan baik dan mulai mengotak-atiknya. Hasilnya? Bug baru muncul di fitur yang tadinya sudah beres.


Solusinya adalah merancang sistem yang bisa dikembangkan tanpa dimodifikasi. Definisikan kontrak lewat interface, lalu setiap perilaku baru cukup mengimplementasikannya:

✦

03 / 05

L — LISKOV SUBSTITUTION

Liskov Substitution Principle
"Subtype harus bisa menggantikan parent-nya tanpa merusak perilaku."


Prinsip ini diperkenalkan oleh Barbara Liskov pada 1987 dan merupakan fondasi dari inheritance yang benar. Intinya sederhana: kalau kode bekerja dengan tipe induk, ia harus tetap bekerja dengan subtipe-nya tanpa perlu tahu perbedaannya.


Kasus klasik yang melanggar prinsip ini: kelas Penguin yang inherit dari Bird, tapi method fly()-nya melempar exception karena penguin tidak bisa terbang. Ini bukan inheritance yang benar.

✦

04 / 05

I — INTERFACE SEGREGATION

Interface Segregation Principle
"Jangan paksa kelas mengimplementasikan method yang tidak mereka butuhkan."


Masalah ini muncul ketika developer membuat satu interface besar yang mencoba mengakomodir semua kemungkinan. Interface Machine dengan method print(), scan(), dan fax() terdengar komprehensif — tapi apa yang terjadi pada SimplePrinter yang hanya bisa cetak?


Ia terpaksa mengimplementasikan scan() dan fax() yang kosong atau melempar exception. Ini adalah interface yang "gemuk" dan berbahaya.

✦

05 / 05

D — DEPENDENCY INVERSION

Dependency Inversion Principle
"Bergantung pada abstraksi, bukan implementasi konkret."


Ini prinsip yang paling mengubah cara berpikir dalam arsitektur software. Modul tingkat tinggi (business logic) tidak boleh tahu detail implementasi modul tingkat rendah. Keduanya harus bergantung pada abstraksi.


Kalau OrderService langsung memanggil Stripe, apa yang terjadi saat klien minta ganti ke PayPal? Kamu harus bongkar dan modifikasi seluruh OrderService. Padahal OrderService seharusnya tidak peduli payment provider mana yang digunakan.

Hasilnya adalah kode yang lebih mudah diubah, lebih mudah diuji, dan lebih mudah diperluas — tanpa rasa takut merusak sesuatu yang sudah berjalan. Itulah yang membedakan kode yang sekadar "berfungsi" dengan kode yang benar-benar dirancang.