AOP vs Fitur

Aspect Oriented Programming (AOP) adalah paradigma pemrograman yang cukup populer. Artikel Wikipedia dengan baik menjelaskan motivasi untuk pendekatan ini.



AOP adalah alat yang sangat baik untuk konsep global, seperti: logging, yang, secara langsung, tidak mempengaruhi logika kode.

Namun, masalah dengan AOP ditemukan ketika digunakan untuk persyaratan bisnis seperti otorisasi. Aspek tersebut harus terlihat jelas dalam kode yang sesuai sehingga pengembang dapat segera melihat ketika membaca kode sumber apakah mereka diterapkan dengan benar. Kerangka kerja AOP biasanya menyelesaikan masalah ini dengan anotasi:

@RequireRole(Role.Admin) // clearly visible aspect fun updateUserPermissions(…) { // logic here } 

Namun, dalam hal keterbacaan, tidak jauh berbeda dari pendekatan fungsional, menggunakan metode requireRole alih-alih anotasi.

Catatan Penerjemah : dalam artikel asli, ekspresi ketika ditulis ulang dengan cara fungsional atau pendekatan fungsional digunakan, yang dapat diartikan sebagai menggunakan pendekatan fungsional atau panggilan fungsi langsung / spesifik. Artikel tersebut memiliki contoh yang dapat diartikan dengan cara yang berbeda.

Juga:

1. Di masa depan, kita akan kembali ke konsep Fungsi Orde Tinggi

2. Artikel tersebut menemukan aspek kata, yaitu bahasa Inggris dan konsep dalam aspek AOP

 fun updateUserPermissions(…) { requireRole(Role.Admin) // throws SecurityException // logic here } 

Selain itu, pendekatan fungsional memiliki keuntungan penskalaan untuk pemeriksaan kontrol akses yang lebih kompleks, seperti analisis parameter metode, sebelum memutuskan peran pengguna yang diperlukan.

Hal yang sama berlaku untuk jenis aspek lainnya, seperti transaksi. Sayangnya, secara fungsional menghadirkan konsep yang lebih kompleks di Jawa rumit dan tidak nyaman, yang menciptakan popularitas buatan kerangka kerja AOP dalam ekosistem Jawa.

Di Kotlin, alih-alih pendekatan transaksi mirip Java menggunakan AOP dan anotasi seperti ini:

 @Transactional fun updateUserPermissions(…) { // logic here } 

Ini juga dapat dibaca dan terlihat bersih ketika ditulis ulang tanpa penjelasan, dengan pendekatan fungsional.

 fun updateUserPermissions(…) = transactional { // logic here } 

Keuntungan dari pendekatan ini adalah bahwa Anda selalu dapat menekan Ctrl / Cmd + Klik pada deklarasi fungsi transaksional dalam IDE Anda dan segera lihat apa tepatnya yang dilakukannya. Yang biasanya tidak mungkin dilakukan dengan kerangka kerja AOP yang umum digunakan. Bahkan ketika navigasi ke kode aspek disediakan menggunakan plugin IDE, dekripsi logikanya membutuhkan pengetahuan tentang API multifungsi dan / atau konvensi yang terpisah.

Sayangnya, ada masalah dengan penskalaan cara mengganti anotasi AOP di Kotlin. Untuk kasus ketika beberapa aspek diterapkan pada fungsi yang sama, dengan akumulasi kurung kurawal dan indentasi:

 fun updateUserPermissions(…) = logged { transactional { // logic here } } 

Solusinya adalah membuat fungsi tingkat tinggi untuk mempertahankan kode yang dapat diterima saat menerapkan beberapa aspek:

 fun updateUserPermissions(…) = loggedTransactional { // logic here } 

Kelemahan lain dari pendekatan fungsional adalah bahwa aspek-aspek seperti logging memerlukan akses ke parameter metode. Mereka biasanya tersedia dalam kerangka kerja AOP melalui API khusus, tetapi menggunakan fungsi bahasa Kotlin standar Anda tidak dapat dengan mudah mengaksesnya. Jadi, untuk benar-benar menyajikan contoh nyata dari aspek logging, dalam bentuk yang murni fungsional, Anda masih perlu menulis sejumlah besar kode pelat boiler :

 fun updateUserPermissions(params: Params) = logged("updateUserPermissions($params)") { // logic here } 

Pertimbangan ini masih menjadikan AOP alat logging yang disukai ketika Anda benar-benar perlu memilikinya secara global dan konsisten dalam aplikasi Anda. Pada saat yang sama, menggunakan AOP untuk fungsi seperti otorisasi dan transaksi adalah penyalahgunaan, mengingat abstraksi fungsional yang kaya yang tersedia di Kotlin. Fungsinya mengatasi persyaratan ini dengan lebih baik dan lebih bersih.

Sebagai kesimpulan, saya akan mengatakan bahwa perbaikan lebih lanjut dari abstraksi fungsional untuk memberikan pengganti yang lebih baik untuk AOP bisa menjadi vektor yang menjanjikan untuk pengembangan bahasa Kotlin di masa depan. Kerangka kerja AOP berbasis Java biasanya spesifik-JVM dan dianggap sebagai sulap, sementara abstraksi fungsional Kotlin benar-benar lintas platform dan transparan bagi pengguna.

Catatan Penerjemah :
1. Artikel tentang medium (ind) .
2. Penulis artikel asli adalah Roman Elizarov (Team Lead JetBrains, mengerjakan koroutine dan lib Kotlin, pemrograman olahraga / ICPC, konkurensi & algoritme, matematika / keuangan kuantitatif; sebelumnya Devexperts). Tentang Habr elizarov