Menulis perangkat lunak adalah tindakan kreatif, dan pengembangan Android tidak terkecuali. Ini tidak hanya tentang membuat sesuatu yang berfungsi. Ini tentang merancang aplikasi yang dapat tumbuh, beradaptasi, dan tetap mudah dipelihara seiring waktu.

Sebagai pengembang Android yang telah menghadapi tantangan arsitektur yang tak terhitung jumlahnya, saya telah menemukan bahwa mematuhi prinsip-prinsip SOLID dapat mengubah bahkan kode yang paling rumit menjadi sistem yang bersih. Ini bukanlah prinsip abstrak, tetapi cara yang hasil-orientatif dan dapat diulang untuk menulis kode yang kuat, scalable, dan mudah dipelihara.

Artikel ini akan memberikan wawasan tentang bagaimana prinsip-prinsip SOLID dapat diterapkan dalam pengembangan Android melalui contoh-contoh nyata, teknik praktis, dan pengalaman dari tim WhatsApp Meta.

Mengenal Prinsip SOLID

Prinsip-prinsip SOLID, yang diajukan oleh Robert C. Martin, adalah lima prinsip desain untuk pemrograman berorientasi objek yang menjamin arsitektur perangkat lunak yang bersih dan efisien.

• Prinsip Tanggung Jawab Tunggal (SRP): Sebuah kelas harus memiliki satu dan hanya satu alasan untuk berubah.
• Prinsip Terbuka/Tertutup (OCP): Entitas perangkat lunak harus terbuka untuk perluasan tetapi tertutup untuk modifikasi.
• Prinsip Substitusi Liskov (LSP): Subtip harus dapat digantikan oleh tip dasar mereka.
• Prinsip Segregasi Antarmuka (ISP): Antarmuka harus spesifik klien dan tidak memaksa implementasi metode yang tidak digunakan.
• Prinsip Inversi Ketergantungan (DIP): Modul tingkat tinggi harus bergantung pada abstraksi, bukan pada modul tingkat rendah.

Dengan mengintegrasikan prinsip-prinsip ini ke dalam pengembangan Android, kita dapat menciptakan aplikasi yang lebih mudah untuk diskalakan, diuji, dan dipelihara.

Prinsip Tanggung Jawab Tunggal (SRP): Mengalirkan Tanggung Jawab

Prinsip Tanggung Jawab Tunggal adalah dasar penulisan kode yang dapat dipelihara. Ini menyatakan bahwa setiap kelas harus memiliki satu kekhawatiran yang diambil alih. Sebuah pola anti yang umum adalah mempertimbangkan Aktivitas atau Fragmen sebagai “Kelas Dewa” yang menangani tanggung jawab mulai dari rendering UI, kemudian pengambilan data, penanganan kesalahan, dll. Pendekatan ini membuat ujian dan pemeliharaan menjadi mimpi buruk.

Dengan SRP, pisahkan kekhawatiran yang berbeda menjadi komponen yang berbeda: misalnya, dalam aplikasi berita, buat atau baca berita.

class NewsRepository {
fun fetchNews(): List {
// Menangani logika pengambilan data
}
}

class NewsViewModel(private val newsRepository: NewsRepository) {
fun loadNews(): LiveData {
// Mengelola keadaan UI dan aliran data
}
}

class NewsActivity : AppCompatActivity() {
// Menangani hanya rendering UI
}

Setiap kelas memiliki hanya satu tanggung jawab; oleh karena itu, mudah diuji dan dimodifikasi tanpa memiliki efek samping.

Dalam pengembangan Android modern, SRP sebagian besar diimplementasikan bersama dengan arsitektur yang disarankan menggunakan Jetpack. Misalnya, logika yang terkait dengan manipulasi data mungkin berada di dalam ViewModel, sedangkan Aktivitas atau Fragmen hanya harus peduli dengan UI dan interaksi. Pengambilan data mungkin didelegasikan ke modul terpisah, baik dari database lokal seperti Room atau lapisan jaringan seperti Retrofit. Ini mengurangi risiko kelas UI membengkak, karena setiap komponen hanya mendapatkan satu tanggung jawab. Secara bersamaan, kode Anda akan jauh lebih mudah diuji dan didukung.

Prinsip Terbuka/Tertutup (OCP): Merancang untuk Perluasan

Prinsip Terbuka/Tertutup menyatakan bahwa sebuah kelas harus terbuka untuk perluasan tetapi tidak untuk modifikasi. Ini lebih masuk akal untuk aplikasi Android karena mereka terus-menerus ditingkatkan dan menambahkan fitur baru.

Contoh terbaik tentang bagaimana menggunakan prinsip OCP dalam aplikasi Android adalah antarmuka dan kelas abstrak. Misalnya:

interface PaymentMethod {
fun processPayment(amount: Double)
}

class CreditCardPayment : PaymentMethod {
override fun processPayment(amount: Double) {
// Implementasi untuk pembayaran kartu kredit
}
}

class PayPalPayment : PaymentMethod {
override fun processPayment(amount: Double) {
// Implementasi untuk pembayaran PayPal
}
}

Menambahkan metode pembayaran baru tidak memerlukan perubahan pada kelas yang ada; itu memerlukan membuat kelas baru. Ini adalah tempat sistem menjadi fleksibel dan dapat diskalakan.

Dalam aplikasi yang dibuat untuk perangkat Android, Prinsip Terbuka/Tertutup cukup berguna ketika datang ke fitur toggle dan konfigurasi yang diambil secara dinamis. Misalnya, jika aplikasi Anda memiliki antarmuka AnalyticsTracker yang melaporkan acara ke layanan analitik yang berbeda, Firebase dan Mixpanel, dan pelacakan internal kustom, setiap layanan baru dapat ditambahkan sebagai kelas terpisah tanpa perubahan pada kode yang ada. Ini menjaga modul analitik Anda terbuka untuk perluasan – Anda dapat menambahkan pelacak baru – tetapi tertutup untuk modifikasi: Anda tidak menulis ulang kelas yang ada setiap kali Anda menambahkan layanan baru.

Prinsip Substitusi Liskov (LSP): Memastikan Penggantian

Prinsip Substitusi Liskov menyatakan bahwa subkelas harus dapat digantikan oleh kelas dasar mereka, dan perilaku aplikasi tidak boleh berubah. Dalam Android, prinsip ini fundamental untuk merancang komponen yang dapat digunakan kembali dan dapat diprediksi.

Misalnya, sebuah aplikasi menggambar:

abstract class Shape {
abstract fun calculateArea(): Double
}

class Rectangle(private val width: Double, private val height: Double) : Shape() {
override fun calculateArea() = width * height
}

class Circle(private val radius: Double) : Shape() {
override fun calculateArea() = Math.PI * radius * radius
}

Kedua Rectangle dan Circle dapat digantikan oleh yang lain secara bergantian tanpa kegagalan sistem, yang berarti bahwa sistem tersebut fleksibel dan mengikuti LSP.

Pertimbangkan RecyclerView.Adapter subclass di Android. Setiap subclass adapter memperluas dari RecyclerView.Adapter<VH> dan mengoverride fungsi inti seperti onCreateViewHolder, onBindViewHolder, dan getItemCount. RecyclerView dapat menggunakan subclass apa pun secara bergantian selama metode-metode tersebut diimplementasikan dengan benar dan tidak merusak fungsionalitas aplikasi Anda. Di sini, LSP dipertahankan, dan RecyclerView Anda dapat fleksibel menggantikan subclass adapter apa pun sesuai keinginan.

Prinsip Segregasi Antarmuka (ISP): Antarmuka yang Ramping dan Fokus

Dalam aplikasi yang lebih besar, umum untuk mendefinisikan antarmuka dengan tanggung jawab yang terlalu banyak, terutama sekitar jaringan atau penyimpanan data. Sebagai gantinya, pecah menjadi antarmuka yang lebih kecil dan lebih terarah. Misalnya, antarmuka ApiAuth yang bertanggung jawab untuk endpoint autentikasi pengguna harus berbeda dari antarmuka ApiPosts yang bertanggung jawab untuk posting blog atau umpan sosial. Pemisahan ini akan mencegah klien yang hanya memerlukan metode terkait posting dari dipaksa untuk bergantung pada dan mengimplementasikan panggilan autentikasi, sehingga menjaga kode Anda, serta cakupan pengujian, lebih ramping.

Prinsip Segregasi Antarmuka berarti bahwa alih-alih memiliki antarmuka besar, beberapa antarmuka yang lebih kecil harus digunakan. Prinsip ini mencegah situasi di mana kelas mengimplementasikan metode yang tidak perlu.

Misalnya, alih-alih memiliki satu antarmuka besar yang mewakili tindakan pengguna, pertimbangkan kode Kotlin:

interface Authentication {
fun login()
fun logout()
}

interface ProfileManagement {
fun updateProfile()
fun deleteAccount()
}

Kelas yang mengimplementasikan antarmuka ini dapat fokus hanya pada fungsionalitas yang mereka butuhkan, sehingga membersihkan kode dan membuatnya lebih mudah dipelihara.

Prinsip Inversi Ketergantungan (DIP): Mengabstraksikan Ketergantungan

Prinsip Inversi Ketergantungan mempromosikan pemisahan dengan memastikan modul tingkat tinggi bergantung pada abstraksi daripada implementasi konkret. Prinsip ini sangat sesuai dengan praktik pengembangan Android modern, terutama dengan kerangka kerja injeksi ketergantungan seperti Dagger dan Hilt.

Misalnya:

class UserRepository @Inject constructor(private val apiService: ApiService) {
fun fetchUserData() {
// Mengambil data pengguna dari abstraksi
}
}

Di sini, UserRepository bergantung pada abstraksi ApiService, membuatnya fleksibel dan dapat diuji. Pendekatan ini memungkinkan kita untuk menggantikan implementasi, seperti menggunakan layanan mock selama pengujian.

Kerangka kerja seperti Hilt, Dagger, dan Koin memfasilitasi injeksi ketergantungan dengan menyediakan cara untuk menyediakan ketergantungan ke komponen Android, menghilangkan kebutuhan untuk menginstansiasi mereka secara langsung. Dalam repositori, misalnya, alih-alih menginstansiasi implementasi Retrofit, Anda akan menyuntikkan abstraksi – misalnya, antarmuka ApiService. Dengan cara itu, Anda dapat dengan mudah beralih ke implementasi jaringan – misalnya, layanan mock untuk pengujian lokal – dan tidak perlu mengubah apa pun dalam kode repositori Anda. Dalam aplikasi nyata, Anda dapat menemukan bahwa kelas dianotasi dengan @Inject atau @Provides untuk menyediakan abstraksi ini, sehingga membuat aplikasi Anda modular dan ramah pengujian.

Manfaat Praktis dari Prinsip SOLID

Mengadopsi prinsip-prinsip SOLID dalam pengembangan Android menghasilkan manfaat yang nyata:

1. Pengujian yang Ditingkatkan: Kelas dan antarmuka yang terfokus membuatnya lebih mudah untuk menulis pengujian unit.
2. Pemeliharaan yang Ditingkatkan: Pemisahan kekhawatiran yang jelas memudahkan debugging dan pembaruan.
3. Skalabilitas: Desain modular memungkinkan penambahan fitur yang mulus.
4. Kolaborasi: Kode yang terstruktur dengan baik memfasilitasi kerja tim dan mengurangi waktu onboarding untuk pengembang baru.
5. Optimasi Kinerja: Arsitektur yang ramping dan efisien meminimalkan pemrosesan dan penggunaan memori yang tidak perlu.

Aplikasi Dunia Nyata

Dalam aplikasi yang kaya fitur, seperti aplikasi e-commerce atau jejaring sosial, penerapan prinsip-prinsip SOLID dapat sangat mengurangi risiko regressi setiap kali fitur atau layanan baru ditambahkan. Misalnya, jika persyaratan baru memerlukan alur pembelian dalam aplikasi, Anda dapat memperkenalkan modul terpisah yang akan mengimplementasikan antarmuka yang diperlukan (Pembayaran, Analitik) tanpa menyentuh modul yang ada. Pendekatan modular ini, yang didorong oleh SOLID, memungkinkan aplikasi Android Anda untuk beradaptasi dengan cepat dengan tuntutan pasar dan menjaga kode basis dari menjadi spaghetti seiring waktu.

Saat bekerja pada proyek besar yang memerlukan banyak pengembang untuk berkolaborasi, sangat disarankan untuk menjaga kode basis yang kompleks dengan prinsip-prinsip SOLID. Misalnya, memisahkan pengambilan data, logika bisnis, dan penanganan UI dalam modul obrolan membantu mengurangi kemungkinan regressi saat menskalakan kode dengan fitur baru. Demikian pula, penerapan DIP sangat penting untuk mengabstraksikan operasi jaringan, sehingga memungkinkan perubahan dengan hampir tidak ada gangguan antara klien jaringan.

Kesimpulan

Lebih dari sekadar panduan teoretis, prinsip-prinsip SOLID sebenarnya adalah filosofi praktis untuk menciptakan perangkat lunak yang tangguh, adaptif, dan mudah dipelihara. Dalam dunia pengembangan Android yang cepat berubah, dengan persyaratan yang berubah hampir secepat teknologi, ketaatan pada prinsip-prinsip ini menyediakan landasan yang kuat untuk kesuksesan.

Kode yang baik tidak hanya tentang membuat sesuatu yang berfungsi – itu tentang menciptakan sistem yang dapat terus berfungsi dan tumbuh dengan kebutuhan yang berkembang. Dengan menerima prinsip-prinsip SOLID, Anda tidak hanya akan menulis kode yang lebih baik, tetapi juga membangun aplikasi yang menyenangkan untuk dikembangkan, diskalakan, dan dipelihara.