Penerapan Clean Architecture di Android Studio — Kotlin PART — 1
Assalamualaikum wr wb. semoga para pembaca selalu diberi kesehatan dan semangat untuk membaca.
Pada artikel kali ini penulis akan berbagi cara penerapan Clean Architecture di android studio. setelah membaca rangkaian artikel berikut diharapkan pembaca memahami apa itu clean architecture dan bagaimana cara menerapkannya di android studio.
Apa itu Clean Architecture?
Berdasarkan referensi diatas, Clean Architecture adalah salah satu solusi arsitektur yang ditawarkan oleh Uncle Bob.
Singkatnya Clean Architecture adalah bagaimana kita membuat code menjadi lebih robust, maintainable, and testable. dengan menekankan ke penerapan SOLID Principle.
Untuk lengkapnya tentang Clean Architecture berikut ada refrensi Berbahasa Indonesia
Tujuan clean architecture
Kalau di Design Pattern seperti (MVC, MVP, MVVM) bertujuan agar kode tidak menumpuk di dalam Main-Thread/UI-Thread dan mencegah terjadinya Memory Leak dan ANR, Clean Architecture sendiri bertujuan untuk memudahkan ketika dalam suatu pengembangan aplikasi. Contohnya saat kita mau menambah, menghapus, merubah fitur atau melakukan migrasi bahasa pemrogramman dengan resiko yang minim. “Anggap saja Clean Architecture adalah pelengkap sebuah Design Pattern.”
Clean Architecture Layer
Kalau kalian sedang belajar tentang clean architecture kalian akan sering bertemu dengan lingkaran seperti bawang berikut dan tidak paham maksudnya 😀
Jujur penulis juga belum terlalu paham saat menulis artikel ini, tapi secara garis besar adalah Pemisahan layer berdasarkan JOBnya masing masing. contoh Presenter,Gateways, Controllers tidak akan tau dan tidak perlu tau apa yang ada di dalam Entities. Sama halnya di entities tidak perlu tau data yang disediakan mau digunakan untuk apa.
Kalau dibuat dialog bisa seperti ini
Presenter : “Eh USECASE ini ada DATA-A aku kirim lewat function 1 yaa jangan lupa laporan jika berhasil ( Return BOOLEAN) ” — — (presenter mengirim event ke usecase)
Usecase : “Oke Siappp PRESENTER” — — (usecase menerima event)
Usecase : “wah, bang entity maunya dibungkus dulu DATA-A => {DATA-A}” (DATA- A diproses di function 1 sehingga jadi {DATA-A})
Usecase : “Permisi Bang Entity ini ada {DATA-A} di function 1 silakan diproses dan minta laporannya juga bang :)” — — (data dikirim ke ENTITY)
Entity : “Oke Usecase tunggu sebentar ya” — — (Entity pun memproses datanya ke repository atau ke local dan membuat laporan)
Entity : “Ini Usecase Laporannya” — — (Entity mengirim laporan ke usecase berupa Long -1 atau 1 yang bisa dirubah ke Boolean di function 1)
Usecase : “Oke Bang Entity Terima Kasih.” — — (USECASE menerima laporan dari Entity di function 1)
Usecase : “Tadi Presenter mintanya laporannya berhasil atau tidak kan. oke saya rubah dulu” — — (USECASE merubah ke true jika 1 dan false jika -1)
Usecase : “Presenter Ini laporan yang diminta” — — (USECASE mengirim laporan ke presenter lewat function 1 berupa Boolean)
Presenter : “Oke Usecase…. Kalau laporannya berhasil jadi yang ditampilkan tampilan 1, kalau gagal tampilan 2” — — (Presenter menerima laporan dan merubah tampilan berdasarkan laporan yang diterima dari USECASE)
Jadi Presenter dan Entity tidak tau bahwa data pernah dirubah oleh Usecase. Sama Halnya jika di perusahaan Developer tidak tau proses yang dilakukan Designer dalam membuat Asset untuknya.
Dan Apabila ada perubahan di dalam 1 layer tidak akan mempengaruhi layer yang lain
Sekian pembahasan dari teori Clean Architecture semoga pembaca-pembaca semua bisa memahami apa yang ingin saya sampaikan. PART Selanjutnya mulai Implementasi di Android Studio.
Kalau Misalkan Ada Pertanyaan Saran atau Kritik bisa email ke 4mirfor3v3r@gmail.com (OPEN FOR DISSCUSSION)
