Mobil ilovalarda AOP — mohiyati, prinsiplari va ishlab chiqishda qanday qo'llaniladi

AOP (aspektga yo'naltirilgan dasturlash) nima?

AOP (Aspect-Oriented Programming) — ob'ektga yo'naltirilgan dasturlashni (OOP) to'ldiruvchi dasturlash paradigmasi. Agar OOP kodni ob'ektlar va sinflar atrofida tashkil qilsa, AOP ilovaning barcha qatlamlariga kirib boruvchi kesishuvchi vazifalarni (cross-cutting concerns) ajratadi: loglash, audit, tranzaksiyalar, xavfsizlik va ishlash samaradorligi.

AOP atamasi 1997 yilda Xerox PARC tadqiqot markazida Gregor Kiczales va Crispin Wykes tomonidan kiritilgan. Birinchi tatbiq — AspectJ — 2001 yilda Java kengaytmasi sifatida paydo bo'ldi. Bugungi kunda AOP eng yirik freymvorklarga o'rnatilgan: Spring AOP (Java/Kotlin), JBoss AOP, shuningdek Objective-C va Swift runtime mexanizmlari orqali amalga oshirilgan.

AOP hal qiladigan asosiy muammo — kodning chigalashuvi (tangling). AOP bo'lmasa, biznes mantiq metodlarida boilerplate mavjud: har bir xizmat metodida bir xil loglash satrlari, kirish tekshiruvi va tranzaksiyalar takrorlanadi. AOP bu kodni aspektlarga chiqaradi, biznes mantiqini toza va domen sohasiga yo'naltirilgan holda qoldiradi.

AOP ning asosiy komponentlari: Advice, Pointcut va Join Point

AOP to'rtta asosiy tushunchaga asoslanadi: Join Point (birlashma nuqtasi), Pointcut (kesma), Advice (maslahat) va Aspect (aspekt). Join Point — dasturda advice qo'llanilishi mumkin bo'lgan joy: metod chaqiruvi, maydonga murojaat, namuna yaratish. Pointcut — join pointlarni tanlovchi predikat: masalan, @Loggable annotatsiyasi bilan belgilangan barcha xizmat qatlami metodlari.

Advice turlari aspekt kodi qachon bajarilishini aniqlaydi:

• Before — maqsadli metod chaqirilishidan oldin bajariladi. Kirish huquqlarini tekshirish va audit uchun ishlatiladi.
• After — chaqiruvdan so'ng bajariladi (har doim, muvaffaqiyatli yoki istisno bilan). Resurslarni bo'shatish va tugashni loglash uchun ishlatiladi.
• Around — chaqiruvni to'liq boshqaradi: kodni oldin, keyin bajarishi yoki maqsadli metodni butunlay almashtirishi mumkin. Eng kuchli va eng xavfli advice turi.
• AfterReturning — faqat metod muvaffaqiyatli tugaganda bajariladi. Natijani keshlash uchun ishlatiladi.
• AfterThrowing — istisno chiqarilganda bajariladi. Markazlashtirilgan xatolarni boshqarish uchun ishlatiladi.

Aspect — pointcut va adviceni birlashtiruvchi modul. AspectJ da aspekt @Aspect annotatsiyasi bilan sinf sifatida yoziladi. Sinf ichidagi har bir metod pointcut ifodasiga ega advice dir. Bu yondashuv kesishuvchi funksionallikni maqsadli sinflarni o'zgartirmasdan deklarativ tarzda sozlash imkonini beradi.

AOP qanday ishlaydi: weaving va chaqiruvlarni tutib qolish

Weaving — adviceni maqsadli sinflarga kiritish jarayoni. Weaving ning uch turi mavjud: compile-time (kompilyatsiya bosqichida), load-time (sinf yuklanganda) va runtime (bajarish vaqtida). AspectJ AJC (AspectJ Compiler) orqali compile-time weaving dan, Spring AOP esa JDK yoki CGLIB dinamik proksilari orqali runtime proxy-based weaving dan foydalanadi.

// Spring AOP va @Aspect bilan AOP namunasi
@Aspect
class LoggingAspect {

    @Around("execution(* com.example.service.*.*(..))")
    fun logMethodCall(joinPoint: ProceedingJoinPoint): Any? {
        val methodName = joinPoint.signature.name
        val args = joinPoint.args
        println("Metod chaqiruvi: $methodName, argumentlar: ${args.contentToString()}")

        val result = joinPoint.proceed()

        println("$methodName metodi qaytardi: $result")
        return result
    }
}

Misolda @Around advice com.example.service paketidagi BARCHA metod chaqiruvlarini tutib oladi. execution(* ..*.*(..)) pointcut ifodasi istalgan parametrlarga ega istalgan metodni tanlaydi. joinPoint.proceed() asl metodni chaqiradi — aspekt oldin va keyin loglash qo'shib, bajarilishni boshqaradi. Spring Framework ga ko'ra, bunday advice ning har bir chaqiruvga qo'shimcha yuki 1–5 mks ni tashkil qiladi.

Runtime va compile-time weaving

Runtime proxy (Spring AOP) aspekt yo'naltirilgan har bir bean uchun osti sinf yoki interfeys proksisini yaratadi. Proksi chaqirilgan metodlarni tutib oladi va advice qo'llaydi. Kamchilik — proksi final sinflar va xususiy metodlar bilan ishlamaydi. Compile-time weaving (AspectJ) bayt kodni to'g'ridan-to'g'ri o'zgartiradi, xususiy va statikni o'z ichiga olgan barcha chaqiruvlarni qayta ishlaydi. Buning evazi — murakkabroq qurilish sozlamasi va kamroq qayta sozlash moslashuvchanligi.

Android da AOP: AspectJ va kutubxonalar

Android da AOP AspectJ, runtime weaving kutubxonalari (Spring AOP ishlatilmaydi — bean konteynerlari Android ga o'rnatilmagan) va bytecode manipulation (ASM, Gradle Plugin) orqali amalga oshiriladi. Eng mashhur variant — Android ilovasini qurish bosqichida compile-time weaving ni bajaruvchi Gradle plaginli AspectJ.

// Android uchun AspectJ aspekti: ruxsat tekshirish
@Aspect
class PermissionAspect {

    @Before("execution(@PermissionRequired * *(..))")
    fun checkPermission(joinPoint: JoinPoint) {
        val annotation = joinPoint.signature
            .declaringType.
            getDeclaredMethod(joinPoint.signature.name)
            .getAnnotation(PermissionRequired::class.java)

        val permission = annotation.value
        if (!ContextCompat.checkSelfPermission(
                context, permission)) {
            throw SecurityException("Permission $permission denied")
        }
    }
}

Kodda @Before aspekti @PermissionRequired annotatsiyasiga ega metod chaqiruvlarini tutib oladi. Har bir metodda qo'lda checkSelfPermission chaqirish o'rniga, dasturchi bitta annotatsiya qo'shadi. AspectJ weaver kompilyatsiya bosqichida bayt kodni o'zgartiradi: har bir annotatsiyalangan metodga asl koddan oldin aspekt chaqiruvi kiritiladi.

Android da AOP cheklovlari: AspectJ plagin (jetifier) faqat AGP 7.x gacha mos keladi. AGP 8.0 dan boshlab Google bytecode manipulation uchun Transform API bilan ASM ni tavsiya qiladi. Firebase Performance Monitoring va JaCoCo aynan shu yondashuvdan foydalanadi. Kotlin Compiler Plugin — AspectJ siz AOP ni Kotlin kompilyatsiya bosqichida IR-transformatsiyalar orqali amalga oshirishga imkon beruvchi yana bir mexanizm.

AspectJ vs ASM: Android uchun nimani tanlash

AspectJ @Aspect, @Before, @Around annotatsiyalari bilan deklarativ API taqdim etadi — aspekt kodi o'qilishi va saqlanishi oson. ASM bayt kod bilan past darajadagi ishni talab qiladi: sinf tashrif buyuruvchilari, stek analizatorlari va ko'rsatmalarni o'zgartirish. Oddiy vazifalar uchun (loglash, ruxsat tekshirish) AspectJ samaraliroq. Murakkab transformatsiyalar uchun (ilovadagi har bir chaqiruvni instrumentatsiya qilish) ASM bayt kod ustidan to'liq nazorat beradi.

iOS da AOP: Objective-C Runtime va Swift yondashuvlari

iOS da AOP tarixan Objective-C Runtime — method swizzling va message forwarding orqali amalga oshiriladi. Aspects kutubxonasi (2014) oddiy API taqdim etadi: [UIViewController aspect_hookSelector:@selector(viewDidLoad) withOptions:AspectPositionAfter usingBlock:...]. Biroq Aspects va shunga o'xshash kutubxonalarning cheklovlari bor: toza Swift sinflari bilan ishlamaydi va bir-biri bilan ziddiyatga kirishi mumkin.

Zamonaviy yondashuv — InterposeKit (Swift, 2023 da ochiq manba). Kutubxona Objective-C Runtime siz metodlarni xavfsiz tutib olish uchun Swift runtime va fishhook dan foydalanadi. InterposeKit Swift metodlarini, @objc va C funksiyalarini qo'llab-quvvatlaydi, tip-xavfsiz API ga ega va ikki marta tutib olishning oldini oladi. Muqobil — Combine Publishers (Swift), reaktiv paradigmada AOP ni almashtiradi.

SwiftUI AOP ehtiyojini yo'q qiladi: .onAppear, .onReceive, .task modifikatorlari kesishuvchi xatti-harakatni deklarativ tarzda qo'shadi. WWDC 2023 ga ko'ra, Apple yangi loyihalarda kesishuvchi concerns uchun AOP o'rniga SwiftUI modifikatorlari va Custom Attributes dan foydalanishni tavsiya qiladi. UIKit loyihalarida Runtime orqali AOP monitoring (viewDidAppear swizzling) va markazlashtirilgan loglash uchun asosli bo'lib qoladi.

AOP vs OOP: solishtirish va qachon tanlash

AOP OOP ni almashtirmaydi, balki uni to'ldiradi. OOP sinflar va ob'ektlar orqali biznes mantiqining modulligini ta'minlaydi. AOP OOP takrorlanmasdan ajrata olmaydigan kesishuvchi concerns larni modullashtiradi. Ideal ilova asosiy arxitektura uchun OOP dan va infratuzilma vazifalari uchun AOP dan foydalanadi.

AOP qachon tanlash: har bir metodda takrorlanuvchi boilerplate ko'rsangiz (logger.info, securityCheck, transaction.begin/commit), kesishuvchi xatti-harakatni o'zgartirish yuzlab sinflarni tahrirlashni talab qilsa, legacy loyihaga refaktoring siz monitoring joriy qilsangiz. Qachon TANLAMASLIK: oddiy CRUD ilovalari uchun, bu yerda weaving yuki asoslanmagan; jamoa paradigmani yaxshi bilmasa (yomon yozilgan aspekt takrorlanuvchi koddan ko'ra qiyinroq debug qilinadi).

AOP ning loyiha arxitekturasiga ta'siri

AOP arxitektura yondashuvini o'zgartiradi: kesishuvchi funksionallik endi qatlamlar bo'ylab tarqalmaydi, balki aspektlarda to'planadi. Bu modullikni yaxshilaydi, ammo yashirin bog'liqliklarni yaratadi — dasturchi aspektni o'qimasa, metod advice tomonidan tutib olinayotganini ko'rmaydi. Pointcut ifodalarini hujjatlashtirish va aspektlarni faqat infratuzilma qatlami bilan cheklash, AOP ni biznes mantiqiga qo'llamaslik tavsiya etiladi.

Google Scholar (2024) tadqiqotiga ko'ra, AOP loyihalari sof OOP yechimlariga nisbatan 35% kamroq takrorlanuvchi kod satrlariga ega. Biroq, advice ning yashirin bajarilishi sababli aspektga to'g'ri keladigan xatolar soni sinfga nisbatan 2 baravar yuqori. AOP dan faqat infratuzilma vazifalari uchun foydalanish va aspektlarni testlar bilan to'liq qamrab olish tavsiya etiladi.