Prinsip Arsitektur dalam Pengembangan Mobile: Apa Itu, Jenis, dan Cara Menerapkannya

Prinsip SOLID

Prinsip arsitektur — adalah fondasi kode berkualitas. SOLID adalah akronim yang diperkenalkan oleh Robert Martin («Paman Bob») yang menggambarkan lima prinsip desain berorientasi objek. Mengikuti SOLID membuat kode lebih fleksibel, dapat diuji, dan tahan terhadap perubahan. Pelanggaran prinsip arsitektur adalah salah satu penyebab utama utang teknis.

Mari kita periksa setiap prinsip. Single Responsibility Principle (SRP) — setiap kelas harus memiliki hanya satu alasan untuk berubah. Open/Closed Principle (OCP) — kelas terbuka untuk ekstensi tetapi tertutup untuk modifikasi. Liskov Substitution Principle (LSP) — objek dari subtipe harus dapat menggantikan objek tipe dasar tanpa merusak logika. Interface Segregation Principle (ISP) — banyak antarmuka khusus lebih baik daripada satu antarmuka umum. Dependency Inversion Principle (DIP) — bergantung pada abstraksi, bukan pada implementasi konkret.

Menurut analisis SonarQube (2025), pelanggaran prinsip SOLID terjadi pada 68% proyek komersial. Masalah yang paling umum adalah pelanggaran SRP (35%) dan ISP (22%). Di IT Sectr, kami menerapkan SOLID pada tahap tinjauan arsitektur — ini membantu mengidentifikasi masalah sebelum mereka berkembang menjadi utang teknis.

Single Responsibility Principle (SRP)

SRP (Prinsip Tanggung Jawab Tunggal) — yang paling penting dan sekaligus prinsip SOLID yang paling sering dilanggar. Ia menyatakan: sebuah kelas harus memiliki hanya satu alasan untuk berubah. Jika sebuah kelas melakukan terlalu banyak, sulit untuk diuji, diubah, dan dipahami.

Pelanggaran tipikal adalah kelas yang secara bersamaan memproses data, menyimpannya ke database, dan mengirim notifikasi email. Contoh di bawah menunjukkan pelanggaran SRP di Kotlin dan cara memperbaikinya.

// Pelanggaran SRP — kelas melakukan tiga hal berbeda
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Validasi data
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Simpan ke database
        val user = User(email, name)
        database.save(user)
        
        // 3. Kirim notifikasi
        emailService.sendWelcomeEmail(email, name)
    }
}

// Perbaikan — bagi menjadi tiga kelas
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

Dalam versi yang diperbaiki, setiap kelas bertanggung jawab atas tugasnya sendiri: UserValidator — untuk validasi, UserRepository — untuk penyimpanan, NotificationService — untuk notifikasi. Ini membuat kode dapat diuji dan digunakan kembali — Anda dapat mengganti implementasi database tanpa mengubah logika validasi.

GRASP dan Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — sembilan prinsip arsitektur untuk mendistribusikan tanggung jawab antar objek, dijelaskan oleh Craig Larman. Tidak seperti SOLID, GRASP menjawab pertanyaan «kelas mana yang harus berisi metode ini?». Pola kunci: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, prinsip keterkaitan minimal) — aturan sederhana: sebuah objek hanya boleh berkomunikasi dengan tetangga terdekatnya. Tidak boleh menulis a.getB().getC().doSomething() — ini menciptakan keterkaitan yang kuat antar kelas. LoD meningkatkan penggunaan kembali dan menyederhanakan pengujian.

Di IT Sectr, kami memeriksa kepatuhan LoD selama Tinjauan Kode. Jika sebuah metode «melewati» tiga atau lebih objek, itu adalah sinyal bahwa arsitektur perlu disederhanakan. Pelanggaran LoD adalah salah satu Code Smell yang paling umum dalam proyek besar.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) dan YAGNI (You Ain't Gonna Need It) — tiga prinsip arsitektur dasar yang dikenal oleh setiap pengembang. Meskipun sederhana, pelanggaran terus terjadi.

DRY — jangan duplikasi kode. Jika logika yang sama muncul di dua tempat, ekstrak ke metode atau kelas bersama. Duplikasi adalah sumber utama bug: perbaikan di satu tempat lupa diterapkan di tempat lain. DRY tidak berarti Anda tidak boleh memiliki kode yang mirip — yang penting adalah logika bisnis tidak terulang.

KISS — semakin sederhana, semakin baik. Solusi kompleks dengan banyak abstraksi dan pewarisan seringkali berlebihan. Mulailah dengan solusi sederhana dan buat lebih kompleks hanya jika diperlukan. YAGNI — jangan menulis kode untuk fungsionalitas yang mungkin diperlukan «suatu hari nanti». Ini menyebabkan penggembungan basis kode dan meningkatkan kompleksitas pemeliharaan.

DRY — Don't Repeat Yourself

DRY — ini bukan hanya tentang tidak adanya salin-tempel. Ini adalah prinsip yang menyatakan bahwa setiap bagian pengetahuan atau logika harus memiliki representasi tunggal yang tidak ambigu dalam sistem. Duplikasi bisa eksplisit (kode yang disalin) dan implisit (logika yang sama di lapisan berbeda).

Di IT Sectr, kami menggunakan metrik analisis kode untuk mendeteksi duplikasi. Alat seperti SonarQube dan Detekt menunjukkan persentase kode yang duplikat. Nilai di atas 5% adalah alasan untuk refactoring. Namun, penting untuk diingat: DRY tidak boleh dicapai dengan mengorbankan abstraksi yang salah — terkadang dua bagian kode yang mirip lebih baik dibiarkan apa adanya jika menggabungkannya akan mempersulit pemahaman.

Separation of Concerns dan Modularitas

Separation of Concerns (SoC) — prinsip arsitektur di mana sistem dibagi menjadi bagian-bagian independen (concerns), masing-masing menyelesaikan tugasnya sendiri. Contoh klasik adalah pemisahan lapisan: presentasi, logika bisnis, akses data. Setiap lapisan hanya bergantung pada lapisan di bawahnya.

Modularitas — tingkat di mana suatu sistem dapat dipecah menjadi modul-modul. Modul adalah kelompok kelas yang terkait secara logis dengan antarmuka yang terdefinisi dengan baik. Modul harus memiliki keterkaitan rendah (low coupling) dan kohesi tinggi (high cohesion).

Kohesi vs Keterkaitan

Kohesi (Cohesion) — ukuran seberapa banyak elemen dalam modul yang sama terkait satu sama lain. Kohesi tinggi itu baik: sebuah kelas melakukan satu hal dan melakukannya dengan baik. Keterkaitan rendah (Low coupling) — ukuran seberapa independen modul satu sama lain. Keterkaitan rendah itu baik: mengubah satu modul tidak merusak yang lain.

Arsitektur ideal adalah kohesi tinggi dan keterkaitan rendah. Dalam praktiknya, ini berarti: sebuah kelas berisi metode yang bekerja pada data yang sama (kohesi), dan hanya bergantung pada abstraksi, bukan pada implementasi konkret (keterkaitan). Ketidakseimbangan mengarah ke «Objek Dewa» atau «kode spageti».

Utang Teknis dan Code Smell

Utang teknis (Technical Debt) — metafora yang diperkenalkan oleh Ward Cunningham yang menggambarkan «bunga» yang dibayar tim untuk keputusan arsitektur yang kurang optimal dan pelanggaran prinsip arsitektur. Seperti utang keuangan, utang teknis bisa disengaja (kami memutuskan untuk melakukannya dengan cepat, akan kami ulangi nanti) dan tidak disengaja (arsitektur buruk karena kurang pengalaman).

Code Smell — tanda-tanda permukaan dari masalah mendalam dalam kode. Istilah ini dipopulerkan oleh Martin Fowler dalam buku «Refactoring». Code Smell tipikal: metode panjang, kelas besar, rantai panggilan panjang, duplikasi kode, penggunaan komentar yang berlebihan (daripada kode yang jelas).

Di IT Sectr, utang teknis dilacak di Jira sebagai tugas terpisah. Setiap sprint, kami mengalokasikan 20% waktu untuk refactoring dan pembayaran utang. Bekerja secara sistematis dengan utang teknis adalah satu-satunya cara untuk menghindari situasi di mana menambahkan fitur baru membutuhkan waktu lebih lama daripada mengembangkannya dari awal.