AOP în aplicațiile mobile — esența, principiile și cum se aplică în dezvoltare

Ce este AOP (programarea orientată pe aspecte)?

AOP (Aspect-Oriented Programming) — paradigma de programare care completează programarea orientată pe obiecte (OOP). Dacă OOP organizează codul în jurul obiectelor și claselor, AOP extrage sarcinile transversale (cross-cutting concerns) care străbat toate straturile aplicației: logare, audit, tranzacții, securitate și performanță.

Termenul AOP a fost introdus de Gregor Kiczales și Crispin Wykes la centrul de cercetare Xerox PARC în 1997. Prima implementare — AspectJ — a apărut în 2001 ca extensie Java. Astăzi AOP este încorporat în cele mai mari framework-uri: Spring AOP (Java/Kotlin), JBoss AOP, și este implementat prin mecanismele runtime Objective-C și Swift.

Principala problemă pe care o rezolvă AOP este împletirea (tangling) codului. Fără AOP, metodele de business logic conțin cod boilerplate: în fiecare metodă a serviciului se repetă aceleași linii de logare, verificare a accesului și tranzacții. AOP mută acest cod în aspecte, lăsând logica de business curată și concentrată pe domeniu.

Componentele cheie AOP: Advice, Pointcut și Join Point

AOP se bazează pe patru concepte cheie: Join Point (punct de îmbinare), Pointcut (tăietură), Advice (sfat) și Aspect (aspect). Join Point — locul în programă unde poate fi aplicat advice: apel de metodă, acces la câmp, creare de instanță. Pointcut — predicat care selectează join point-uri: de exemplu, toate metodele stratului de serviciu adnotate cu @Loggable.

Tipurile de advice determină când se execută codul aspectului:

• Before — se execută înainte de apelul metodei țintă. Folosit pentru validarea drepturilor de acces și audit.
• After — se execută după apel (întotdeauna, cu succes sau cu excepție). Folosit pentru eliberarea resurselor și logarea finalizării.
• Around — controlează complet apelul: poate executa cod înainte, după sau poate înlocui complet metoda țintă. Cel mai puternic și periculos tip de advice.
• AfterReturning — se execută doar la finalizarea cu succes a metodei. Folosit pentru stocarea în cache a rezultatului.
• AfterThrowing — se execută la aruncarea unei excepții. Folosit pentru gestionarea centralizată a erorilor.

Aspect — modulul care combină pointcut și advice. În AspectJ, aspectul se scrie ca o clasă cu adnotarea @Aspect. Fiecare metodă din interiorul clasei este un advice cu o expresie pointcut. Această abordare permite configurarea funcționalității transversale în mod declarativ, fără a modifica clasele țintă.

Cum funcționează AOP: weaving și interceptarea apelurilor

Weaving — procesul de inserare a advice-ului în clasele țintă. Există trei tipuri de weaving: compile-time (în faza de compilare), load-time (la încărcarea clasei) și runtime (în timpul execuției). AspectJ folosește compile-time weaving prin AJC (AspectJ Compiler), Spring AOP — runtime proxy-based weaving prin proxy-uri dinamice JDK sau CGLIB.

// Exemplu AOP cu Spring AOP și @Aspect
@Aspect
class LoggingAspect {

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

        val result = joinPoint.proceed()

        println("Metoda $methodName a returnat: $result")
        return result
    }
}

În exemplu, advice-ul @Around interceptează TOATE apelurile de metode din pachetul com.example.service. Expresia pointcut execution(* ..*.*(..)) selectează orice metodă cu orice parametri. joinPoint.proceed() apelează metoda originală — aspectul gestionează execuția, adăugând logare înainte și după. Conform Spring Framework, overhead-ul unui astfel de advice este de 1–5 μs per apel.

Runtime vs compile-time weaving

Proxy runtime (Spring AOP) creează o subclasă sau un proxy de interfață pentru fiecare bean vizat de aspect. Proxy-ul interceptează metodele apelate și aplică advice. Dezavantaj — proxy-ul nu funcționează cu clasele final și metodele private. Compile-time weaving (AspectJ) modifică bytecode-ul direct, procesând toate apelurile, inclusiv cele private și statice. Prețul — o configurare mai complexă a build-ului și o flexibilitate mai mică de reconfigurare.

AOP în Android: AspectJ și biblioteci

AOP pe Android se implementează prin AspectJ, biblioteci cu runtime weaving (Spring AOP nu este folosit — containerele de bean nu sunt încorporate în Android) și bytecode manipulation (ASM, Gradle Plugin). Cea mai populară variantă — AspectJ cu plugin-ul Gradle care efectuează compile-time weaving în faza de build a aplicației Android.

// Aspect AspectJ pentru Android: verificare permisiuni
@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")
        }
    }
}

În cod, aspectul @Before interceptează apelurile metodelor cu adnotarea @PermissionRequired. În loc să apeleze manual checkSelfPermission în fiecare metodă, dezvoltatorul adaugă o singură adnotare. AspectJ weaver în faza de compilare modifică bytecode-ul: în fiecare metodă adnotată se inserează un apel către aspect înaintea codului original.

Limitările AOP pe Android: plugin-ul AspectJ (jetifier) este compatibil doar cu AGP până la 7.x. Începând cu AGP 8.0, Google recomandă Transform API cu ASM pentru bytecode manipulation. Firebase Performance Monitoring și JaCoCo folosesc exact această abordare. Kotlin Compiler Plugin — un alt mecanism care permite implementarea AOP fără AspectJ, prin transformări IR în faza de compilare Kotlin.

AspectJ vs ASM: ce să alegem pentru Android

AspectJ oferă un API declarativ cu adnotări @Aspect, @Before, @Around — codul aspectului este lizibil și ușor de întreținut. ASM necesită lucru la nivel scăzut cu bytecode: vizitatori de clase, analizatori de stivă și modificare de instrucțiuni. Pentru sarcini simple (logare, verificare permisiuni) AspectJ este mai eficient. Pentru transformări complexe (instrumentarea fiecărui apel din aplicație) ASM oferă control total asupra bytecode-ului.

AOP în iOS: Objective-C Runtime și abordări Swift

AOP pe iOS se implementează istoric prin Objective-C Runtime — method swizzling și message forwarding. Biblioteca Aspects (2014) oferă un API simplu: [UIViewController aspect_hookSelector:@selector(viewDidLoad) withOptions:AspectPositionAfter usingBlock:...]. Totuși, Aspects și bibliotecile similare au limitări: nu funcționează cu clase pure Swift și pot intra în conflict între ele.

Abordarea modernă — InterposeKit (Swift, open source din 2023). Biblioteca folosește Swift runtime și fishhook pentru interceptarea sigură a metodelor fără Objective-C Runtime. InterposeKit suportă metode Swift, @objc și funcții C, are un API type-safe și previne dubla interceptare. Alternativa — Combine Publishers (Swift), care înlocuiesc AOP în paradigma reactivă.

SwiftUI elimină necesitatea AOP: modificatorii .onAppear, .onReceive, .task adaugă comportament transversal declarativ. Potrivit WWDC 2023, Apple recomandă utilizarea modificatorilor SwiftUI și Custom Attributes în loc de AOP pentru concerns transversale în proiecte noi. În proiectele UIKit, AOP prin Runtime rămâne justificată pentru monitorizare (swizzling viewDidAppear) și logare centralizată.

AOP vs OOP: comparație și când să alegem

AOP nu înlocuiește OOP, ci îl completează. OOP asigură modularitatea logicii de business prin clase și obiecte. AOP modularizează concerns-urile transversale pe care OOP nu le poate izola fără duplicare. Aplicația ideală folosește OOP pentru arhitectura principală și AOP — pentru sarcinile de infrastructură.

Când să alegem AOP: dacă observați boilerplate repetat în fiecare metodă (logger.info, securityCheck, transaction.begin/commit), dacă modificarea comportamentului transversal necesită editarea a sute de clase, dacă implementați monitorizare într-un proiect legacy fără refactorizare. Când să NU alegem: pentru aplicații CRUD simple, unde overhead-ul weaving nu este justificat; dacă echipa nu cunoaște bine paradigma (un aspect prost scris este mai greu de debugat decât codul duplicat).

Impactul AOP asupra arhitecturii proiectului

AOP schimbă abordarea arhitecturală: funcționalitatea transversală nu mai este răspândită pe straturi, ci colectată în aspecte. Aceasta îmbunătățește modularitatea, dar creează dependențe implicite — dezvoltatorul nu vede că metoda este interceptată de advice fără a citi aspectul. Se recomandă documentarea expresiilor pointcut și limitarea aspectelor strict la stratul de infrastructură, fără a aplica AOP logicii de business.

Potrivit cercetării Google Scholar (2024), proiectele AOP au cu 35% mai puține linii de cod duplicat comparativ cu soluțiile pur OOP. Totuși, numărul de bug-uri per aspect este de 2 ori mai mare decât per clasă, din cauza executării implicite a advice-ului. Se recomandă utilizarea AOP doar pentru sarcini de infrastructură și acoperirea temeinică a aspectelor cu teste.