SoC dalam pengembangan mobile: apa itu, prinsip dan pemisahan tanggung jawab

Apa arti singkatan SoC

SoC adalah singkatan dari Separation of Concerns — "pemisahan tanggung jawab" atau "pemisahan area minat". Dalam konteks pemrograman, istilah concern merujuk pada fungsionalitas yang dapat dipisahkan: menampilkan antarmuka pengguna, memproses klik, validasi data, komunikasi jaringan, atau bekerja dengan database. Prinsip SoC mengelompokkan kode di sekitar area ini sehingga perubahan pada satu area tidak memengaruhi yang lain.

Singkatan SoC banyak digunakan dalam literatur teknis, diskusi arsitektur, dan dokumentasi framework. Misalnya, dalam dokumentasi Android Architecture Components, SoC disebutkan berulang kali sebagai motivasi untuk memisahkan ViewModel dan View. Di komunitas iOS, istilah ini digunakan saat membahas masalah Massive View Controller — konsekuensi langsung dari tidak adanya SoC.

Penting untuk dipahami bahwa SoC bukanlah tindakan satu kali, melainkan proses berkelanjutan. Seiring pertumbuhan aplikasi, muncul area tanggung jawab baru dan arsitektur perlu ditinjau ulang. Basis kode yang baik melalui beberapa iterasi pembagian sebelum mencapai kondisi stabil di mana setiap concern terisolasi dan terkelola.

SoC vs Separation of Concerns

Separation of Concerns dan singkatannya SoC menunjukkan prinsip yang sama. Perbedaannya hanya pada konteks penggunaan: nama lengkap digunakan dalam dokumen formal, materi pendidikan, dan saat menjelaskan konsep kepada pengembang baru. SoC nyaman dalam diskusi teknis, code review, dan dokumentasi di mana keringkasan penting.

Di lingkungan profesional, kedua istilah dapat dipertukarkan. Seorang pengembang dapat mengatakan "di sini SoC dilanggar" atau "ini melanggar Separation of Concerns" — maknanya tidak berubah. Namun, dalam lowongan pekerjaan dan persyaratan arsitektur, nama lengkap lebih sering muncul, sementara di chat dan code review — singkatan. Pengetahuan tentang kedua varian diperlukan untuk memasuki industri dengan nyaman.

Ada kebingungan terminologis: singkatan SoC juga digunakan dalam konteks perangkat keras untuk System-on-a-Chip (sistem pada chip). Dalam pengembangan mobile, konteks selalu jelas dari lingkungan — jika diskusi menyangkut arsitektur kode, itu merujuk pada Separation of Concerns. Dalam artikel ini, SoC di mana-mana merujuk pada prinsip pemisahan tanggung jawab.

Bagaimana SoC diterapkan dalam arsitektur mobile

Arsitektur tiga lapis — cara paling umum untuk menerapkan SoC dalam aplikasi mobile. Ini membagi kode menjadi Presentation (UI), Domain (logika bisnis), dan Data (bekerja dengan sumber). Setiap lapisan berisi tipe kelas yang ditentukan secara ketat dan diisolasi dari tetangganya melalui antarmuka. Pendekatan ini sama efektifnya untuk proyek iOS, Android, dan Flutter.

Lapisan Presentation dan ViewModel

View dan ViewModel membentuk lapisan presentasi. View bertanggung jawab untuk merender antarmuka dan menyampaikan peristiwa pengguna. ViewModel menyimpan status layar dan mengubah data dari lapisan Domain ke format yang siap ditampilkan. ViewModel tidak memiliki referensi ke Activity, Fragment, atau UIViewController — ini memastikan SoC antara UI dan logika.

Misalnya, di Android Jetpack, ViewModel bertahan dari rotasi layar sementara UI dibuat ulang. Tanpa SoC, kita harus menyimpan status di Activity, mencampur manajemen siklus hidup dengan data. ViewModel memecahkan tugas ini secara terisolasi, menunjukkan implementasi murni dari prinsip pemisahan tanggung jawab.

Lapisan Domain dan Use Cases

Use Cases berisi aturan bisnis yang independen dari platform. Lapisan ini tidak mengimpor Android SDK, iOS UIKit, atau Flutter framework. Use Case menerima data dari Repository, menerapkan logika bisnis padanya, dan mengembalikan hasil. Berkat SoC, satu Use Case dapat digunakan kembali di layar dan platform yang berbeda.

Contoh klasik — ValidateAndSaveUseCase untuk formulir pendaftaran. Ini memeriksa kebenaran email dan kata sandi, memanggil UserRepository untuk menyimpan, dan mengembalikan ValidationResult. Baik UI maupun database tidak mengetahui aturan validasi — keduanya terkonsentrasi di satu tempat, menyederhanakan perubahannya.

Lapisan Data dan Repository

Repository mengabstraksi sumber data dari seluruh aplikasi. ViewModel tidak tahu dari mana data berasal — REST API, GraphQL, database lokal, atau cache. Repository memutuskan sumber mana yang akan digunakan dan menyembunyikan logika ini di belakang antarmuka. Ini adalah SoC antara pengambilan data dan konsumsinya.

DataSource memberikan pemisahan yang lebih dalam: RemoteDataSource hanya bertanggung jawab atas permintaan HTTP, LocalDataSource — untuk bekerja dengan Room, CoreData, atau SharedPreferences. Repository menggabungkannya dengan menerapkan strategi caching. Setiap DataSource dapat diganti secara independen, yang sangat penting saat migrasi antar server atau database.

Sistem DataSource bertingkat semacam itu menerapkan SoC pada tingkat infrastruktur: komunikasi jaringan, penyimpanan lokal, dan caching — concerns terpisah, masing-masing dengan logika dan siklus hidupnya sendiri. Saat mengganti klien HTTP, hanya RemoteDataSource yang berubah, sementara Repository dan lapisan di atasnya tetap tidak tersentuh, menegaskan nilai praktis dari pemisahan tanggung jawab.

SoC dalam pola arsitektur

MVP (Model-View-Presenter) — salah satu pola pertama yang secara eksplisit menerapkan SoC dalam pengembangan mobile. Presenter berisi logika dan mengelola View melalui antarmuka. View bersifat pasif — hanya menampilkan apa yang dikatakan Presenter. Pemisahan menyederhanakan pengujian: Presenter diuji tanpa emulator, dan View tetap sangat sederhana sehingga tidak ada yang bisa rusak.

MVVM menambahkan pengikatan reaktif: View berlangganan perubahan ViewModel melalui Observable atau StateFlow. ViewModel tidak menyimpan referensi ke View, menghilangkan risiko kebocoran memori dan memisahkan concerns dengan lebih kuat. Di Android, MVVM menjadi standar berkat Jetpack ViewModel dan LiveData, di iOS — berkat Combine dan RxSwift.

Clean Architecture Robert Martin membawa SoC ke pemisahan radikal menjadi lingkaran. Lingkaran luar (framework dan driver) bergantung pada lingkaran dalam (entitas), bukan sebaliknya. Dalam praktiknya, proyek mobile jarang mengimplementasikan keempat lingkaran — lapisan Domain dan Data di sekitar Presentation sudah cukup. Namun prinsip ketergantungan "ke dalam" itu sendiri memberikan keuntungan signifikan saat mengganti framework.

// View — hanya tampilan, tanpa logika
final class LoginViewController: UIViewController {
    let viewModel: LoginViewModel

    func loginTapped() {
        viewModel.login(emailField.text, passwordField.text)
    }
}

// ViewModel — berisi logika layar, tidak mengenal UIKit
final class LoginViewModel {
    private let loginUseCase: LoginUseCase

    func login(email: String?, password: String?) {
        loginUseCase.execute(email, password)
    }
}

// Use Case — logika bisnis, tidak bergantung pada platform
final class LoginUseCase {
    private let repo: AuthRepository

    func execute(email: String?, password: String?) {
        guard let e = email, let p = password else { return }
        repo.authenticate(e, p)
    }
}

Contoh menunjukkan tiga tingkat SoC: LoginViewController hanya meneruskan peristiwa, LoginViewModel mengelola status, LoginUseCase berisi aturan bisnis. Setiap kelas diuji secara independen, dan mengganti framework UI tidak memengaruhi Use Case.

Pelanggaran tipikal SoC di proyek mobile

Massive View Controller — pelanggaran SoC paling umum di iOS. Kelas yang mengelola UI, memproses permintaan jaringan, mengurai JSON, dan menyimpan data melanggar prinsip di semua tingkat. Solusi — ekstrak setiap tanggung jawab ke komponen terpisah: NetworkingService, JSONParser, CoreDataStack, sisakan ViewController hanya untuk mengelola View.

Di Android, masalah serupa — God Activity atau God Fragment. Satu aktivitas yang memuat data, memvalidasi formulir, menampilkan dialog, dan memperbarui UI. Diobati dengan memperkenalkan ViewModel dan Repository yang mengambil alih manajemen status dan data. ViewModel juga melindungi dari kehilangan data saat rotasi layar.

Pelanggaran ketiga — mencampur kode platform dan bisnis. Misalnya, menempatkan permintaan HTTP langsung di SwiftUI View atau Android Composable. Ini membuat kode tidak portabel dan sulit diuji. Pendekatan yang benar — ekstrak permintaan ke Repository yang dipanggil melalui Use Case, dan View hanya berlangganan hasilnya. Setiap elemen sistem menyelesaikan tugasnya dan tidak melampaui batasnya.