Refactoring Ekstrak Class dan Inner Class
Banyak kesempatan refactoring yang terbuka jika kita lebih jeli melihat situasi code nya dan pola pola refactoring dan desain yang sudah ada. Sebagai contoh dalam kesempatan ini kita lihat bagaimana kita bisa meng-ekstrak class dari code yang sudah ada dengan melihat pola yang ada di dalamnya.
Berikut sebuah contoh code dari app android.
Class di atas berkaitan dengan pembukaan bagian tertentu di app secara langsung berdasarkan skema Firebase Dynamic Link. Tanpa terlalu jauh membahas tentang fiturnya secara utuh, kita akan fokuskan ke sebagian code di class di atas yang berhubungan dengan logika program berikut :
Pendeteksian sebuah string URL, apakah ia merupakan sebuah Firebase Dynamic Links Vidio atau bukan.
Logika tersebut ada di dalam fungsi handleIntent di atas.
Refactor Ekstrak Class
Jika kita lihat lagi class di atas, terutama terkait logika pendeteksian Dynamic Links di atas. Kita bisa lihat ada bagian dari class tersebut yang sibuk sendiri. Mereka hanya berurusan di antara mereka sendiri. Jika kita soroti bagian yang terkait, bisa kita lihat seperti di bawah.
Jika ada bagian bagian code di dalam satu komponen yang terlalu intim seperti ini, biasanya bisa kita buat lebih baik modularitasnya dengan melakukan refactoring Ekstrak Class.
Dengan mengambil term dari domain masalah, kita bisa ekstrak class bernama FirebaseDynamicLinksChecker dengan listing code berikut.
Dengan class di atas sudah terekstrak, class asalnya jadi jauh lebih ringkas seperti di bawah.
Dalam buku refactoring edisi baru, tiap refactoring sekarang mempunyai representasi visual kecil sebagai “avatar” dan alat bantu mereferensi masing-masing refactoring. Yang menarik, jika kita lihat visualisasi refactoring ekstrak class mengilustrasikan proses di atas dengan cukup akurat dan intuitif.
Perubahan di atas terlihat sebuah perubahan kode yang sederhana, tapi jika dilakukan dengan konsisten, seiring waktu kode kita akan terdiri dari bagian bagian code yang lebih modular dan lebih mudah diurus dan dikembangkan.
Pemisahan Code Domain dan Infrastruktur
Selain modularitas secara umum, yang juga penting adalah code dengan kondisi alamiah yang berbeda menjadi relatif terpisah. Dalam kasus di atas code yang spesifik berisi logika domain kita terpisah dari kode yang terkait dengan infrastruktur, dalam hal ini Android Runtime dan SDK.
Class FirebaseDynamicLinksChecker yang di ekstrak di atas bersih dari keterkaitan dengan infrastruktur dan bisa dites secara sederhana dengan perangkat unit test ringan (dalam hal ini JUnit). Memakai istilah dari Michael Feather, Class seperti ini, yang hanya berisi computational core. Hal tersebut membuatnya tidak memerlukan Android Test yang lebih mahal secara eksekusi dan kompleksitas karena keterkaitannya dengan runtime dan Platform SDK.
Penamaan yang lebih Sadar Konteks
Salam satu aturan penamaan Clean Code yang penting adalah penamaan yang sadar kontes :
- Tambahkan konteks jika kurang ke dalam nama
- Buang penambahan konteks yang tidak perlu
Singkatnya, info kontekstual dalam penamaan harus secukupnya, tidak boleh lebih atau kurang.
Karena itulah kita mempunya variabel ini di code asal
Karena ia ada di dalam cakupan code yang belum spesifik maka namanya jadi perlu lebih lengkap untuk kebutuhan pembedaan.
Setelah adanya class yang dengan peran yang lebih spesifik, variabel-variabel tersebut bisa menjadi lebih ringkas karena sudah mendapat konteks dari scope lebih luarnya.
Ekstrak Inner Class
Dalam eXtreme Programming ada istilah Refaktor tanpa ampun! (Refactor Mercilessly). Karena itu, code hasil refactor kita sebelumnya, FirebaseDynamicLinksChecker, perlu ditelaah lagi untuk melihat apakah masih ada yang bisa direfaktor lagi.
Jika mengaplikasikan pola yang sama seperti di atas, kita bisa lihat masih ada code dan data yang saling berurusan dengan diri mereka sendiri seperti di bawah ini.
Kita bisa kembali melakukan Ekstrak Class dengan pola yang sama. Tapi dalam hal ini cakupan logika dan data nya relatif kecil dan spesifik/lokal untuk class FirebaseDynamicLinksChecker. Dalam bahasa pemrograman yang mempunyai dukungan Inner Class, ini adalah kasus yang pas untuk pemakaiannya.
Jadi selain refactor Ekstrak Class kita bisa melakukannya lebih spesifik ke arah Ekstrak Inner Class.
Pattern dan Referensi
Berikut beberapa Pattern dan Praktek yang menarik untuk disegarkan berkaitan dengan pembahasan di atas.
Class harus kecil!, Clean Code. Aturan pertama soal Class : harus kecil. Aturan kedua : harus lebih kecil lagi.
Aturan Penamaan, Clean Code. Di dalamnya termasuk poin tentang detail/panjang penamaan yang proporsional terhadap konteks serta penggunaan kosa kata dari domai masalah.
