Kohesi (Cohesion) dalam Pengembangan Mobile: Dasar, Tingkat, dan Cara Meningkatkannya

Apa itu Cohesion

Cohesion (kohesi) — metrik yang mengevaluasi seberapa logis metode, bidang, dan properti dalam satu kelas atau modul saling terhubung. Modul dengan kohesi tinggi menjalankan satu tugas dan hanya berisi elemen yang diperlukan untuk pelaksanaannya. Modul dengan kohesi rendah mencoba melakukan beberapa hal sekaligus — metode-metodenya terhubung secara lemah secara makna.

Dalam konteks pemrograman berorientasi objek, cohesion terkait erat dengan Single Responsibility Principle (S). Jika sebuah kelas memiliki satu tanggung jawab yang jelas, cohesion-nya biasanya tinggi. Jika sebuah kelas menangani UI, logika bisnis, dan komunikasi jaringan sekaligus — cohesion-nya rendah dan kelas tersebut harus dipecah menjadi beberapa kelas terpisah dengan tanggung jawab yang lebih sempit.

Pemahaman tentang cohesion membantu pengembang dalam mengambil keputusan refactoring. Ketika Anda melihat bahwa di dalam sebuah kelas ada metode yang tidak menggunakan bidang kelas, ini adalah sinyal kohesi rendah. Metode semacam itu bisa tidak diperlukan di kelas, atau kelas tersebut dirancang dengan buruk. Berusaha mencapai kohesi tinggi — adalah kerja terus-menerus untuk meningkatkan arsitektur di setiap tingkat kode.

Jenis dan Tingkat Kohesi

Dalam rekayasa perangkat lunak, ada tujuh tingkat cohesion, yang diurutkan dari yang terburuk hingga terbaik. Memahami skala ini memungkinkan penilaian objektif terhadap kualitas modul dan menentukan arah yang harus diambil saat refactoring. Semakin tinggi tingkatnya, semakin mudah dipelihara dan dipahami kodenya.

Kohesi Rendah: kebetulan, logis, dan temporal

Kebetulan (coincidental) — tingkat terburuk, ketika elemen-elemen dalam modul dikelompokkan secara kebetulan, tanpa hubungan logis apa pun. Contoh: kelas Utilities, yang berisi metode format tanggal, pengiriman email, dan perhitungan diskon. Kelas semacam itu tidak dapat dipahami tanpa membaca semua metode, dan perubahan pada satu metode dapat merusak yang lain hanya karena mereka berada di dekatnya.

Logis (logical) kohesi — elemen menjalankan tugas yang terhubung secara logis tetapi berbeda secara esensi. Kelas dengan metode parseJSON, parseXML, dan parseCSV terhubung secara logis dengan topik „parsing”, tetapi setiap metode melakukan pekerjaan yang fundamentally berbeda. Masalah: saat menambahkan format baru (YAML), kelas bertambah dan antarmukanya menjadi membengkak.

Temporal (temporal) kohesi — elemen dikelompokkan berdasarkan waktu eksekusi. Kelas AppInitializer, yang mengonfigurasi database, memuat konfigurasi, menginisialisasi analitik — semua ini terjadi saat aplikasi dimulai, tetapi tugas-tugas itu sendiri tidak terkait satu sama lain. Lebih baik membaginya menjadi Initializer terpisah untuk setiap area tanggung jawab.

Kohesi Sedang: prosedural dan komunikasional

Prosedural (procedural) kohesi muncul ketika elemen digabungkan oleh urutan eksekusi. Modul „Pemrosesan Pesanan” berisi metode validateCart, processPayment, sendConfirmation — setiap metode dipanggil secara ketat setelah yang sebelumnya. Ini lebih baik daripada kohesi kebetulan atau logis, tetapi masih belum ideal: setiap langkah dapat diekstraksi ke modul terpisah.

Komunikasional (communicational) kohesi — elemen bekerja dengan data yang sama. Kelas UserService dengan metode getUser, updateUser, deleteUser digabungkan oleh entitas bersama User. Ini jauh lebih baik daripada kohesi prosedural: kelas memiliki domain subjek yang jelas. Sebagian besar kelas Repository dalam proyek mobile memiliki kohesi komunikasional.

Kohesi Tinggi: fungsional

Fungsional (functional) kohesi — tingkat tertinggi, ketika setiap elemen modul berpartisipasi dalam pelaksanaan satu tugas. Kelas PasswordValidator dengan satu-satunya metode validate, yang memeriksa panjang, keberadaan karakter, dan kompleksitas kata sandi — contoh kohesi fungsional. Jika kelas seperti itu berubah, itu hanya karena aturan validasi kata sandi telah berubah.

Mencapai kohesi fungsional — tujuan utama refactoring arsitektural. Setiap kelas harus memiliki tepat satu alasan untuk berubah. Dalam pengembangan mobile, kohesi fungsional dicapai melalui pemisahan Use Cases terpisah, View kustom, formatter, dan validator. Setiap kelas tersebut adalah blok bangunan lengkap dengan area tanggung jawab yang jelas.

Cohesion vs Coupling

Cohesion dan coupling — dua sisi dari kualitas yang sama. Semakin tinggi cohesion di dalam modul, biasanya semakin rendah coupling antar modul. Sistem yang dirancang dengan baik secara bersamaan berusaha mencapai kohesi tinggi di dalam dan keterkaitan lemah di luar. Aturan ini dianggap fundamental dalam rekayasa perangkat lunak sejak tahun 1970-an.

Rasio cohesion-coupling dapat dianggap sebagai keseimbangan. Jika pengembang mengorbankan cohesion dengan menggabungkan beberapa tugas dalam satu kelas, modul tetangga mendapatkan lebih banyak dependensi — mereka harus merujuk ke kelas yang kelebihan beban ini untuk tujuan yang berbeda, yang meningkatkan coupling. Dan sebaliknya, pemecahan menjadi kelas-kelas kecil dengan kohesi tinggi mengurangi jumlah titik interaksi antar modul.

Dalam praktik, ini berarti: ketika Anda mengekstrak kelas baru dengan kohesi fungsional, Anda sekaligus membebaskan modul lain dari kebutuhan untuk mengetahui detail implementasinya. Misalnya, dengan mengekstrak EncryptionManager ke kelas terpisah dengan kohesi fungsional, Anda memberikan modul lain antarmuka sederhana encrypt/decrypt tanpa perlu memahami detail algoritma enkripsi.

// Kohesi rendah — kelas melakukan semuanya sekaligus
class UserManager {
    fun fetchAndSaveUser(id: String) { }
    fun parseUserJson(json: String): User { }
    fun displayUserName(user: User): String { }
    fun validateEmail(email: String): Boolean { }
}

// Kohesi tinggi — setiap kelas menyelesaikan satu tugas
class UserRepository {
    fun fetchUser(id: String): User { }
}

class UserJsonParser {
    fun parse(json: String): User { }
}

class UserNameFormatter {
    fun format(user: User): String { }
}

class EmailValidator {
    fun isValid(email: String): Boolean { }
}

Contoh menunjukkan perbedaannya: UserManager memiliki kohesi logis — semua metode tentang pengguna, tetapi masing-masing melakukan pekerjaan yang fundamentally berbeda. Setelah refactoring, setiap kelas memiliki kohesi fungsional, dan coupling menurun karena modul lain hanya bergantung pada kelas yang mereka butuhkan, bukan pada seluruh UserManager.

Cara Mengukur Kohesi dalam Kode

LCOM (Lack of Cohesion of Methods) — metrik paling terkenal untuk mengukur kohesi kelas. LCOM menghitung berapa pasang metode tidak menggunakan bidang bersama. Nilai 0 berarti kohesi ideal (semua metode bekerja dengan bidang yang sama), nilai tinggi — kohesi rendah. LCOM4 (versi yang disempurnakan) mempertimbangkan koneksi transitif melalui metode lain.

Dalam pengembangan Android, metrik kohesi dapat diperoleh melalui Detekt dengan aturan TooManyFunctions. Kelas dengan puluhan metode yang menggunakan kelompok bidang yang berbeda kemungkinan besar memiliki kohesi rendah. Di iOS, SwiftLint memiliki aturan file_length dan function_body_length — indikator tidak langsung: file dan metode yang panjang sering menandakan cohesion rendah.

Metode penilaian manual: ajukan pertanyaan „Akankah kelas ini berubah karena satu alasan atau beberapa alasan?” Jika Anda dapat menyebutkan lebih dari satu alasan independen — kelas memiliki kohesi rendah. Tes kedua: „Dapatkah kelas ini dipecah menjadi dua kelas independen?” Jika ya — lakukan. Pemeriksaan rutin cohesion selama code review mencegah munculnya kelas God dan mengurangi utang teknis.

Cara Meningkatkan Cohesion dalam Proyek Mobile

Langkah pertama — terapkan Single Responsibility Principle. Setiap kelas harus memiliki satu tanggung jawab yang jelas. Jika di dalam kelas ada metode yang tidak termasuk dalam tugas utamanya, ekstrak ke kelas terpisah. Teknik Extract Class atau Extract Delegate di IDE mengotomatiskan proses ini. Setelah ekstraksi, periksa apakah kelas asli menjadi lebih fokus.

Langkah kedua — gunakan pola Facade untuk menyederhanakan antarmuka. Jika sebuah kelas menyediakan 20 metode, dan klien hanya menggunakan 3-4 di antaranya, kemungkinan kelas memiliki kohesi rendah — ia menawarkan terlalu banyak fungsionalitas yang beragam. Kelompokkan metode berdasarkan topik dan ekstrak kelas terpisah untuk setiap grup, lalu jadikan kelas asli sebagai facade atau hapus.

Langkah ketiga — perhatikan kelompok bidang. Jika sebuah kelas memiliki bidang yang hanya digunakan oleh sebagian metode — ini adalah indikator kohesi rendah. Bagilah kelas berdasarkan kelompok bidang. Misalnya, jika kelas berisi bidang userRepository, networkClient, dan analyticsTracker, tetapi metode kelompok pertama hanya menggunakan userRepository, dan kelompok kedua — networkClient — ini adalah dua kelas yang berbeda.

Langkah keempat — hindari membuat kelas “utilitas” dengan metode statis sembarangan. Setiap metode statis yang berada di kelas Utils atau Helpers adalah kandidat untuk diekstraksi ke kelas khusus. FormatUtils.dateToString lebih baik dipindahkan ke DateFormatter, dan ValidationUtils.isValidEmail — ke EmailValidator. Ini meningkatkan kohesi setiap kelas dan membuat kode dapat mendokumentasi sendiri.