Pengaruh Penerapan Prinsip SOLID terhadap Maintainability Perangkat Lunak pada Domain Asuransi

20 Agustus 2026  ▪  Kategori: Riset  ▪  Perkiraan baca: 11 menit

Prinsip SOLID sudah lama diyakini memperbaiki kualitas desain. Masalahnya, keyakinan itu jarang disertai angka. Sebagian besar studi yang ada memakai proyek open-source Java berskala besar, di mana pengaruh SOLID sulit dipisahkan dari faktor lain, dan hampir tidak ada yang mengambil domain bisnis dinamis seperti asuransi sebagai objek.

Penelitian ini mencoba mengisi celah itu: mengukur pengaruh penerapan prinsip SOLID terhadap maintainability pada studi kasus proses bisnis asuransi, dengan instrumen metrik standar industri yang sehari-hari dipakai pengembang .NET.

Kenapa domain asuransi

Domain ini dipilih bukan karena kebetulan saya mengerjakannya, melainkan karena karakternya cocok sebagai ujian. Aturan bisnis asuransi — perhitungan premi, pengelolaan jenis polis, validasi kelayakan pengajuan — berubah cukup sering. Justru pada domain semacam inilah kemampuan sebuah desain menyerap perubahan benar-benar teruji.

Tiga pertanyaan yang dijawab penelitian ini:

1. Bagaimana penerapan SOLID memengaruhi nilai Maintainability Index?
2. Seberapa besar perbedaan Cyclomatic Complexity antara implementasi ber-SOLID dan implementasi terstruktur tanpa SOLID?
3. Adakah trade-off yang signifikan antara penerapan SOLID dan ukuran kode?

Dua artefak yang dibandingkan

Keduanya mengerjakan proses bisnis yang sama, hanya berbeda cara menyusunnya.

Versi A — terstruktur, tanpa SOLID

Satu kelas tunggal bernama WithoutSolidStructured yang memuat seluruh logika secara prosedural: konversi tenor, perhitungan usia akhir tertanggung, validasi kelayakan jiwa dan umum, perhitungan premi jiwa dan umum, penutupan transaksi, serta satu metode orkestrasi ProcessInsurance yang mengoordinasikan semuanya.

public class WithoutSolidStructured
{
    convertTenorToYear()          // konversi tenor
    calculateAgeofEndInsured()    // usia akhir tertanggung
    checkEligibleLife()           // validasi kelayakan — jiwa
    checkEligibleGeneral()        // validasi kelayakan — umum
    premiumCalculatorLife()       // perhitungan premi — jiwa
    premiumCalculatorGeneral()    // perhitungan premi — umum
    closeTransaction()            // penutupan transaksi
    ProcessInsurance()            // orkestrasi seluruh alur
}

Versi B — berorientasi objek, menerapkan kelima prinsip

Logika yang sama didekomposisi ke dalam sembilan tipe: empat antarmuka abstraksi, tiga kelas polis konkret, satu kelas layanan orkestrasi, dan satu implementasi notifikasi.

// Abstraksi
IInsurancePolicy      IEligibilityCheck
IPremiumCalculator    IPolicyNotifier

// Implementasi
LifePolicy      GeneralPolicy      HealthPolicy   // ← tipe tambahan
InsuranceService                                  // orkestrasi
ConsolePolicyNotifier                             // notifikasi

Perhatikan HealthPolicy. Jenis polis ini tidak ada di Versi A — ia ditambahkan tanpa mengubah satu baris pun pada kelas orkestrasi yang sudah ada. Selain menjadi bukti struktural penerapan Open/Closed Principle, keberadaannya membuat perbandingan ini bersifat konservatif: Versi B mengerjakan cakupan fungsional yang lebih luas, namun tetap diukur dengan standar metrik yang sama.

Pemetaan kelima prinsip

Cara mengukurnya

Instrumennya Code Metrics Analyzer bawaan Microsoft Visual Studio 2022 — dipilih justru karena ia alat standar di ekosistem .NET, menghasilkan nilai otomatis tanpa intervensi manual, sehingga datanya objektif dan bisa direplikasi siapa pun. Implementasinya memakai C# 13 pada .NET 9.0.

Indikator utamanya Maintainability Index, dikembangkan Oman dan Hagemeister (1992) dan diadopsi Microsoft:

MI = maks(0, (171 − 5,2·ln(HV) − 0,23·CC − 16,2·ln(LoC)) × 100 / 171)

  HV  = Halstead Volume
  CC  = Cyclomatic Complexity
  LoC = Lines of Code

Zona:  0–19 rendah  │  20–64 sedang  │  65–100 tinggi

Metrik pendukungnya Cyclomatic Complexity (McCabe, 1976), Lines of Code — dipisah antara Lines of Source Code dan Lines of Executable Code — serta Class Coupling. Perbandingan dilakukan head-to-head pada tiga tingkat: proyek, kelas/metode, dan modul orkestrasi.

Hasil: tingkat proyek

Baris terakhir yang paling menarik. Lines of Source Code naik hampir 60%, tapi Lines of Executable Code nyaris tidak bergerak — hanya +2,8%. Artinya hampir seluruh tambahan baris di Versi B bersifat struktural: deklarasi antarmuka, aksesor properti, dan konstruktor. Bukan penambahan logika eksekusi, dan karenanya bukan tambahan beban kognitif.

Hasil: distribusi per unit

Nilai agregat bisa menipu, jadi pengukuran diturunkan ke tingkat metode untuk Versi A dan tingkat tipe untuk Versi B.

Di sinilah temuan yang menurut saya paling bermakna. Pada Versi A, MI antarmetode berkisar 57–100 dengan dua titik lemah: ProcessInsurance (MI 57) dan checkEligibleLife (MI 64). Nilai 57 jatuh ke zona sedang, menjadikan metode itu hotspot pemeliharaan.

Pada Versi B, komponen terburuk pun — LifePolicy dengan MI 81 — masih berada di zona tinggi. Tidak ada satu pun yang jatuh ke zona sedang.

Membaca Cyclomatic Complexity dengan benar

Pada tingkat agregat, total CC justru naik dari 20 menjadi 34. Sekilas terlihat seperti kemunduran, padahal bukan. Kenaikan itu konsekuensi aritmetika dari dekomposisi: Versi B tersebar di sembilan tipe dibanding satu kelas, dan bahkan menambah satu jenis polis. Penjumlahan CC meningkat semata karena unit yang dihitung bertambah banyak.

Perbandingan yang bermakna adalah kompleksitas per unit untuk logika yang setara, yaitu pada modul orkestrasi — ProcessInsurance di Versi A versus InsuranceService.Process di Versi B.

CC modul orkestrasi turun 66,7% karena percabangan berbasis jenis polis digantikan dispatch polimorfik sesuai Liskov Substitution Principle. Seluruh metode di Versi B berada di bawah ambang CC 10 yang direkomendasikan McCabe (1976) serta Thomas et al. (1988).

Jadi yang dilakukan SOLID bukan menghapus kompleksitas — kompleksitas domain tidak bisa dihapus — melainkan mendistribusikannya, dari satu orkestrator padat menjadi banyak unit kecil yang masing-masing bertanggung jawab tunggal.

Trade-off yang nyata dan terukur

Penelitian ini menemukan dua biaya yang tidak kecil: Lines of Source Code naik 59,5%, dan Class Coupling naik 200% dari 2 menjadi 6. Temuan ini mengonfirmasi Lippert dan Roock (2006) bahwa penerapan SOLID menghasilkan lebih banyak kelas dengan ukuran yang lebih kecil.

Namun ada dua faktor yang memitigasinya:

• Lines of Executable Code hampir tidak berubah (36 → 37, +2,8%). Tambahan barisnya bersifat struktural, bukan logika baru yang harus dipahami.
• Coupling-nya mengarah ke abstraksi, bukan ke implementasi konkret. Sesuai Dependency Inversion Principle, ketergantungan jenis ini justru meningkatkan kemudahan pengujian dan substitusi — berbeda dari coupling konkret yang menambah fragility.

Ditambah lagi, sebagian kenaikan LoC mencerminkan fungsionalitas ekstra berupa HealthPolicy. Versi B mengerjakan lebih banyak hal, namun tetap lebih mudah dipelihara.

Posisi terhadap penelitian terdahulu

Kenaikan MI 29,2% sejalan dengan — bahkan sedikit melampaui — temuan Gama et al. (2019) yang melaporkan kenaikan 15–25% setelah refactoring berbasis SOLID. Peningkatan maintainability dan penurunan kompleksitas per unit konsisten dengan Bibiano et al. (2012).

Keterkaitan antara coupling dan kualitas yang ditekankan Chidamber dan Kemerer (1994) serta Subramanyam dan Krishnan (2003) juga relevan, dengan satu catatan penting: coupling yang meningkat di studi ini mengarah ke abstraksi, bukan ke modul konkret. Ini perbedaan yang sering hilang ketika metrik dibaca tanpa melihat arahnya.

Kesimpulan

Penerapan prinsip SOLID berpengaruh positif terhadap maintainability perangkat lunak pada studi kasus proses bisnis asuransi:

• MI agregat naik dari 72 menjadi 93 (+29,2%), dan yang lebih penting, hotspot pemeliharaan tereliminasi.
• Pada logika inti, CC modul orkestrasi turun dari 6 menjadi 2 (−66,7%) dengan mengganti percabangan kondisional menjadi polimorfisme.
• Trade-off-nya signifikan namun dapat diterima: LoSC +59,5% dan Class Coupling +200%, tetapi LoEC nyaris tetap dan tambahan ketergantungan mengarah pada abstraksi.

Kesimpulan praktisnya: manfaat utama SOLID tidak terletak pada pengurangan ukuran kode. Kode ber-SOLID hampir pasti lebih panjang. Manfaatnya ada pada kemudahan pemeliharaan, penyederhanaan logika inti, dan kemudahan memperluas sistem tanpa merusak bagian yang sudah ada.

Kalau ada yang menjanjikan SOLID akan membuat kode Anda lebih ringkas, angka-angka di atas mengatakan sebaliknya.

Keterbatasan

Perlu disampaikan apa adanya. Artefaknya berskala kecil dan bersifat studi kasus tunggal. Pengukuran dilakukan secara statis tanpa data defek aktual. Implementasinya dikerjakan satu pengembang dengan satu IDE. Karena itu generalisasi ke proyek industri berskala besar perlu dilakukan hati-hati.

Penelitian lanjutan yang disarankan: memperluas sampel ke beberapa domain dan proyek yang lebih besar, menambahkan metrik dinamis, serta melakukan pelacakan defek aktual.

Prakoso, B. Pengaruh Penerapan Prinsip SOLID terhadap Maintainability Perangkat Lunak pada Domain Asuransi. Naskah disiapkan untuk Jurnal Teknologi Informasi dan Ilmu Komputer (JTIIK). Program Studi Teknik Informatika, Fakultas Ilmu Rekayasa, Universitas Paramadina, Jakarta.