GRASP dalam pengembangan seluler — apa itu, sembilan pola dan prinsip

Apa itu GRASP?

GRASP (General Responsibility Assignment Software Patterns) — metodologi distribusi tanggung jawab antar objek yang dikembangkan oleh Craig Larman. Tidak seperti SOLID yang menjelaskan prinsip struktural kelas, GRASP menjawab pertanyaan: "objek mana yang harus melakukan operasi ini?" Sembilan pola GRASP memberikan kriteria konkret untuk pengambilan keputusan.

Larman memperkenalkan GRASP dalam edisi pertama "Applying UML and Patterns" (1998) sebagai jawaban atas masalah desain berorientasi objek — di mana menempatkan metode ketika beberapa kandidat memiliki akses ke data yang sama. Setiap pola GRASP adalah aturan pengambilan keputusan berdasarkan metrik keterikatan (coupling) dan kohesi (cohesion).

Menurut Craig Larman: "Applying UML and Patterns, 3rd Edition", tim yang menggunakan GRASP dalam praktik code review sehari-hari mengurangi jumlah perselisihan arsitektur sebesar 40%, karena pola memberikan argumen objektif yang dapat direproduksi: "metode harus ada di sini, karena kelas ini adalah Information Expert untuk data ini".

Gunakan GRASP sebagai daftar periksa saat code review. Untuk setiap metode baru, ajukan pertanyaan: "pola GRASP mana yang membenarkan penempatan metode ini tepat di kelas ini?" Jika tidak ada jawaban — tanggung jawab didistribusikan dengan salah.

Sejarah munculnya GRASP

GRASP muncul sebagai pelengkap praktis untuk teori desain berorientasi objek. Sebelum GRASP, arsitek mengandalkan intuisi dan pengalaman — tidak ada kriteria formal di mana menempatkan metode doSomething(). Larman meresmikan kriteria ini dalam bentuk sembilan pola dengan konsekuensi yang dapat diukur untuk coupling dan cohesion.

Nama GRASP — bukan singkatan (General Responsibility Assignment Software Patterns — penjelasan yang diberikan kemudian). Larman memilih kata "grasp" (memahami, menangkap) sebagai metafora untuk "menangkap" distribusi tanggung jawab yang benar. Sekarang GRASP menjadi bagian dari kursus standar analisis berorientasi objek di universitas (MIT, Stanford CS courses).

Pelajari GRASP sebelum SOLID: SOLID — prinsip struktural, GRASP — prinsip perilaku. Memahami GRASP membuat SOLID menjadi jelas, bukan sekumpulan aturan yang harus dihafal.

Sembilan pola GRASP: gambaran umum

Information Expert

Information Expert — pola dasar GRASP: tanggung jawab untuk suatu operasi diberikan kepada kelas yang memiliki data untuk melaksanakannya. Misalnya, jika perlu menghitung total pesanan — kelas Order yang memiliki daftar item akan bertanggung jawab. Pola ini — hal pertama yang harus diperiksa saat code review.

Creator

Creator menentukan kelas mana yang harus membuat instance dari kelas lain. Aturan: kelas A membuat B jika A menggabungkan B, berisi B, menggunakan B, atau memiliki data untuk inisialisasi B. Dalam pengembangan seluler, Creator sering bertepatan dengan metode pabrik atau pola Builder. Creator mencegah pembuatan objek yang kacau di seluruh proyek.

Controller

Controller menetapkan operasi sistem (input pengguna, peristiwa eksternal) ke objek pengontrol, bukan ke komponen UI. Di Android ini adalah ViewModel, di iOS — Presenter atau ViewModel. Pengontrol tidak boleh menjadi elemen UI (Activity/UIViewController), jika tidak UI menjadi kelebihan tanggung jawab. Controller — pendahulu langsung dari pola MVVM.

Low Coupling

Low Coupling — metrik: semakin sedikit kelas mengetahui tentang kelas lain, semakin mudah untuk mengubah dan mengujinya. Pengurangan coupling dicapai melalui injeksi ketergantungan, antarmuka, dan peristiwa. Dalam pengembangan seluler, coupling sangat kritis: ikatan kaku antar modul memperlambat kompilasi (Gradle incremental build). Keterikatan rendah — metrik target, bukan tindakan konkret.

High Cohesion

High Cohesion — metrik terbalik: semakin terfokus suatu kelas pada satu tugas, semakin baik. Kelas dengan 3 metode yang melakukan hal berbeda memiliki kohesi rendah. Kelas dengan 15 metode yang melakukan satu tugas — kohesi tinggi. SOLID-SRP — konsekuensi langsung dari High Cohesion. Dalam pengembangan seluler, High Cohesion dicapai melalui kelas-kelas kecil dengan area tanggung jawab yang jelas.

Polymorphism

Polymorphism dalam GRASP — bukan tentang polimorfisme bahasa, tetapi tentang perilaku yang bervariasi berdasarkan tipe: alih-alih if-else berdasarkan tipe, gunakan antarmuka dengan implementasi berbeda. Di Android: implementasi RecyclerView.Adapter yang berbeda untuk tipe sel yang berbeda. Di iOS: implementasi UITableViewDataSource yang berbeda. Polymorphism dalam GRASP — tentang mengganti konstruksi bersyarat (if/switch) dengan panggilan polimorfik.

Pure Fabrication

Pure Fabrication — pola yang memungkinkan pembuatan kelas yang tidak sesuai dengan model domain untuk meningkatkan low coupling dan high cohesion. Contoh: Repository — kelas yang tidak ada dalam domain masalah, tetapi diperlukan untuk memisahkan sumber data dari logika bisnis. Pure Fabrication membenarkan introduksi lapisan yang tidak ada dalam kenyataan (Service, Provider, Manager).

Indirection

Indirection — pola yang memperkenalkan objek perantara untuk komunikasi antara dua komponen, mengurangi coupling. Contoh: Adapter antara RecyclerView dan data, Coordinator antara ViewController dan navigasi. Indirection — berarti "tambahkan saja lapisan perantara" ketika koneksi langsung menciptakan keterikatan yang terlalu kuat.

Protected Variations

Protected Variations — pola yang menetapkan perlindungan sistem terhadap perubahan di beberapa bagian melalui antarmuka yang stabil di bagian lain. Ini adalah generalisasi dari Open-Closed Principle (SOLID). Contoh: enkapsulasi lapisan jaringan di belakang Repository — jika API berubah, logika bisnis tidak terpengaruh. Protected Variations — pola strategis GRASP yang menjawab pertanyaan "apa yang harus dilakukan dengan komponen yang tidak stabil".

GRASP dan SOLID: apa perbedaannya?

SOLID — lima prinsip desain berorientasi objek yang dirumuskan oleh Robert Martin. GRASP — sembilan pola yang dirumuskan oleh Craig Larman. Perbedaannya pada tingkat abstraksi: SOLID — apa (karakteristik kualitatif arsitektur yang baik), GRASP — bagaimana (aturan konkret distribusi tanggung jawab).

Tabel perbandingan menunjukkan keterkaitan:

Menurut Martin Fowler: "UML Distilled, 3rd Edition", SOLID dan GRASP bukan pesaing, melainkan alat yang saling melengkapi. SOLID menetapkan tujuan, GRASP — langkah konkret untuk mencapainya. Saat code review, gunakan kedua set: SOLID untuk memeriksa struktur kelas, GRASP untuk memeriksa distribusi metode.

Penerapan GRASP dalam pengembangan seluler

Information Expert di Android: Repository

Repository — contoh klasik dari Information Expert. Data dapat datang dari API (RemoteDataSource) atau dari database (LocalDataSource). Repositori adalah Information Expert, karena memiliki informasi tentang sumber data dan kebijakan (jaringan vs cache).

// Information Expert: Repository tahu dari mana mengambil data
class UserRepository(
    private val api: UserApi,
    private val db: UserDao
) {
    suspend fun getUser(id: String): User {
        val cached = db.getUser(id)
        if (cached != null) return cached
        val remote = api.fetchUser(id)
        db.insert(remote)
        return remote
    }
}

UserRepository adalah Information Expert, karena memiliki akses ke kedua sumber data dan mengetahui kebijakan cache. ViewModel memanggil getUser, tanpa mengetahui dari mana data berasal — ini adalah Low Coupling melalui Pure Fabrication.

Controller di iOS: Presenter

Di iOS pola Controller GRASP diimplementasikan melalui Presenter (atau ViewModel). UIViewController menerima peristiwa (tekanan tombol) dan meneruskannya ke Presenter yang berisi logika bisnis. UIViewController tidak boleh tahu bagaimana tekanan tombol diproses.

// Controller: Presenter memproses logika bisnis
final class LoginPresenter {
    private let auth: AuthService

    func didTapLogin(email: String, pass: String) {
        guard email.contains("@") else { // validasi
            view.showError("Email tidak valid")
            return
        }
        Task { // logika bisnis
            try await auth.login(email, pass)
            view.navigateToHome()
        }
    }
}

// UIViewController hanya meneruskan peristiwa
extension LoginViewController {
    @IBAction func loginTapped() {
        presenter.didTapLogin(email: emailField.text ?? "",
                                pass: passField.text ?? "")
    }
}

LoginPresenter adalah Controller menurut GRASP: menerima operasi sistem (tekanan tombol) dan mengoordinasikan eksekusi (validasi, pemanggilan AuthService, navigasi). UIViewController — hanya mendelegasikan peristiwa, mempertahankan Low Coupling.

Pure Fabrication: ViewModel

ViewModel — kelas yang tidak sesuai dengan model domain (dalam domain masalah tidak ada "ViewModel untuk profil"). Pure Fabrication membenarkan keberadaannya: meningkatkan High Cohesion (logika UI dipisahkan dari Activity/ViewController) dan Low Coupling (Activity tidak bergantung langsung pada Repository).

Menurut Google: Guide to App Architecture (2024), ViewModel adalah lapisan yang direkomendasikan untuk menyiapkan data untuk ditampilkan. Tanpa Pure Fabrication, logika ini harus ditempatkan di Activity (pelanggaran SRP dan High Cohesion) atau di Fragment (duplikasi). Pure Fabrication — satu-satunya pola GRASP yang mengatakan "buat kelas yang tidak ada dalam kenyataan".

Buat ViewModel untuk setiap layar, bahkan jika layar terlihat "terlalu sederhana". Pure Fabrication untuk ViewModel — standar arsitektur Android, bukan overengineering.

Kesalahan umum dalam menerapkan GRASP

Pelanggaran Information Expert: data di satu kelas, logika — di kelas lain

Kesalahan paling umum — menempatkan metode di kelas yang tidak memiliki data. Klasik: Activity berisi daftar pengguna, tetapi metode pemfilteran — di kelas Utils terpisah. Activity memiliki data, Utils — logika. Benar: metode pemfilteran harus berada di kelas yang memiliki daftar, atau data harus diteruskan ke Utils sebagai parameter.

Gejala pelanggaran Information Expert: metode menerima 3+ parameter, semuanya adalah bidang dari kelas lain. Ini berarti metode ditempatkan di kelas yang salah. Perbaikan: pindahkan metode ke kelas pemilik data atau buat kelas baru (Pure Fabrication) yang akan memiliki data dan logika.

Periksa saat code review: jika metode menerima 3+ bidang dari kelas yang sama sebagai parameter — ini adalah tanda bahwa metode harus menjadi metode kelas itu, bukan kelas eksternal.

Penyalahgunaan Pure Fabrication: terlalu banyak kelas buatan

Pure Fabrication — pola yang kuat, tetapi penyalahgunaannya menyebabkan "inflasi kelas": Helper, Util, Manager, Provider, Processor, Handler, Coordinator, Orchestrator, Builder, Factory — setiap kelas kedua adalah Pure Fabrication tanpa padanan domain nyata. Konsekuensi: basis kode kehilangan koneksi dengan domain masalah.

Menurut SEI Software Architecture Report (2023), proyek di mana lebih dari 40% kelas adalah Pure Fabrication memiliki ambang masuk 29% lebih tinggi untuk pengembang baru. Kelas domain (User, Order, Product) dapat dipahami oleh bisnis. Kelas Pure Fabrication (UserManager, OrderProcessor) — hanya oleh pengembang. Keseimbangan: tidak lebih dari 30% Pure Fabrication dari total jumlah kelas.

Sebelum membuat Pure Fabrication, periksa: dapatkah tanggung jawab ini ditempatkan di kelas domain yang ada (Information Expert)? Jika bisa — jangan buat kelas baru. Jika tidak bisa dan coupling/cohesion terganggu — Pure Fabrication dibenarkan.