AOP у мобилним апликацијама — суштина, принципи и како применити у развоју

Шта је AOP (аспектно-оријентисано програмирање)?

AOP (Aspect-Oriented Programming) — програмска парадигма која допуњује објектно-оријентисано програмирање (OOP). Ако OOP организује код око објеката и класа, AOP издваја попречне задатке (cross-cutting concerns) који прожимају све слојеве апликације: логирање, ревизију, трансакције, безбедност и перформансе.

Термин AOP су увели Грегор Кичaлес и Криспин Вајкс у истраживачком центру Xerox PARC 1997. године. Прва имплементација — AspectJ — појавила се 2001. године као проширење Jave. Данас је AOP уграђен у највеће оквире: Spring AOP (Java/Kotlin), JBoss AOP, а такође је имплементиран кроз runtime механизме Objective-C и Swift-а.

Главни проблем који AOP решава је преплитање (tangling) кода. Без AOP-а, методи пословне логике садрже boilerplate: у сваком методу сервиса понављају се исте линије логирања, провере приступа и трансакција. AOP премешта овај код у аспекте, остављајући пословну логику чистом и фокусираном на домен.

Кључне компоненте AOP: Advice, Pointcut и Join Point

AOP се заснива на четири кључна појма: Join Point (тачка спајања), Pointcut (пресек), Advice (савет) и Aspect (аспект). Join Point — место у програму где се може применити advice: позив метода, приступ пољу, креирање инстанце. Pointcut — предикат који бира join point-ове: на пример, сви методи сервисног слоја означени анотацијом @Loggable.

Типови advice-а одређују када се извршава код аспекта:

• Before — извршава се пре позива циљног метода. Користи се за валидацију права приступа и ревизију.
• After — извршава се после позива (увек, успешно или са изузетком). Користи се за ослобађање ресурса и логирање завршетка.
• Around — у потпуности контролише позив: може извршити код пре, после или потпуно заменити циљни метод. Најмоћнији и најопаснији тип advice-а.
• AfterReturning — извршава се само при успешном завршетку метода. Користи се за кеширање резултата.
• AfterThrowing — извршава се при бацању изузетка. Користи се за централизовану обраду грешака.

Aspect — модул који обједињује pointcut и advice. У AspectJ-у аспект се пише као класа са анотацијом @Aspect. Сваки метод унутар класе је advice са pointcut изразом. Овај приступ омогућава конфигурисање попречне функционалности декларативно, без измене циљних класа.

Како ради AOP: weaving и пресретање позива

Weaving — процес убацивања advice-а у циљне класе. Постоје три типа weaving-а: compile-time (у фази компилације), load-time (при учитавању класе) и runtime (током извршења). AspectJ користи compile-time weaving кроз AJC (AspectJ Compiler), Spring AOP — runtime proxy-based weaving кроз динамичке проксије JDK или CGLIB.

// Пример AOP са Spring AOP и @Aspect
@Aspect
class LoggingAspect {

    @Around("execution(* com.example.service.*.*(..))")
    fun logMethodCall(joinPoint: ProceedingJoinPoint): Any? {
        val methodName = joinPoint.signature.name
        val args = joinPoint.args
        println("Позив метода: $methodName, аргументи: ${args.contentToString()}")

        val result = joinPoint.proceed()

        println("Метод $methodName је вратио: $result")
        return result
    }
}

У примеру @Around advice пресреће СВЕ позиве метода у пакету com.example.service. Pointcut израз execution(* ..*.*(..)) бира било који метод са било којим параметрима. joinPoint.proceed() позива оригинални метод — аспект управља извршењем, додајући логирање пре и после. Према Spring Framework-у, overhead таквог advice-а износи 1–5 μs по позиву.

Runtime vs compile-time weaving

Runtime proxy (Spring AOP) креира подкласу или прокси интерфејса за сваки bean на који је усмерен аспект. Прокси пресреће позване методе и примењује advice. Недостатак — прокси не ради са final класама и приватним методима. Compile-time weaving (AspectJ) мења бајт-код директно, обрађујући све позиве, укључујући приватне и статичке. Цена — сложеније подешавање изградње и мања флексибилност реконфигурације.

AOP у Android-у: AspectJ и библиотеке

AOP на Android-у се реализује кроз AspectJ, библиотеке са runtime weaving (Spring AOP се не користи — контејнери bin-ова нису уграђени у Android) и bytecode manipulation (ASM, Gradle Plugin). Најпопуларнија варијанта — AspectJ са Gradle прикључком који извршава compile-time weaving у фази изградње Android апликације.

// AspectJ аспект за Android: провера дозвола
@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")
        }
    }
}

У коду, аспект @Before пресреће позиве метода са анотацијом @PermissionRequired. Уместо ручног позивања checkSelfPermission у сваком методу, програмер додаје једну анотацију. AspectJ weaver у фази компилације мења бајт-код: у сваки анотирани метод убацује се позив аспекта пре оригиналног кода.

Ограничења AOP на Android-у: AspectJ прикључак (jetifier) је компатибилан само са AGP до 7.x. Почев од AGP 8.0, Google препоручује Transform API са ASM-ом за bytecode manipulation. Firebase Performance Monitoring и JaCoCo користе управо овај приступ. Kotlin Compiler Plugin — још један механизам који омогућава имплементацију AOP без AspectJ-а, кроз IR трансформације у фази компилације Kotlin-а.

AspectJ vs ASM: шта одабрати за Android

AspectJ пружа декларативни API са анотацијама @Aspect, @Before, @Around — код аспекта је читљив и одржав. ASM захтева нижеслојни рад са бајт-кодом: посетиоци класа, анализатори стекова и модификација инструкција. За једноставне задатке (логирање, провера дозвола) AspectJ је ефикаснији. За сложене трансформације (инструментирање сваког позива у апликацији) ASM даје потпуну контролу над бајт-кодом.

AOP у iOS-у: Objective-C Runtime и Swift приступи

AOP на iOS-у се историјски реализује кроз Objective-C Runtime — method swizzling и message forwarding. Библиотека Aspects (2014) пружа једноставан API: [UIViewController aspect_hookSelector:@selector(viewDidLoad) withOptions:AspectPositionAfter usingBlock:...]. Међутим, Aspects и сличне библиотеке имају ограничења: не раде са чистим Swift класама и могу бити у конфликту једна са другом.

Савремени приступ — InterposeKit (Swift, отворен 2023). Библиотека користи Swift runtime и fishhook за безбедно пресретање метода без Objective-C Runtime-а. InterposeKit подржава Swift методе, @objc и C функције, има type-safe API и спречава двоструко пресретање. Алтернатива — Combine Publishers (Swift), који замењују AOP у реактивној парадигми.

SwiftUI елиминише потребу за AOP-ом: модификатори .onAppear, .onReceive, .task додају попречно понашање декларативно. Према WWDC 2023, Apple препоручује коришћење SwiftUI модификатора и Custom Attributes уместо AOP-а за попречне concerns у новим пројектима. У UIKit пројектима, AOP кроз Runtime остаје оправдан за праћење (swizzling viewDidAppear) и централизовано логирање.

AOP vs OOP: поређење и када одабрати

AOP не замењује OOP, већ га допуњује. OOP обезбеђује модуларност пословне логике кроз класе и објекте. AOP модуларизује попречне concerns које OOP не може изоловати без дуплирања. Идеална апликација користи OOP за главну архитектуру и AOP — за инфраструктурне задатке.

Када одабрати AOP: ако примећујете понављајући boilerplate у сваком методу (logger.info, securityCheck, transaction.begin/commit), ако промена попречног понашања захтева измену стотина класа, ако уводите праћење у legacy пројекат без рефакторисања. Када НЕ одабрати: за једноставне CRUD апликације, где overhead weaving-а није оправдан; ако тим слабо познаје парадигму (лоше написан аспект је теже debug-овати од дуплираног кода).

Утицај AOP-а на архитектуру пројекта

AOP мења архитектонски приступ: попречна функционалност више није размазана по слојевима, већ сакупљена у аспектима. Ово побољшава модуларност, али ствара имплицитне зависности — програмер не види да метод пресреће advice без читања аспекта. Препоручује се документовање pointcut израза и ограничавање аспеката искључиво на инфраструктурни слој, без примене AOP-а на пословну логику.

Према истраживању Google Scholar (2024), AOP пројекти имају 35% мање линија дуплираног кода у поређењу са чисто OOP решењима. Међутим, број багова по аспекту је 2 пута већи него по класи, због имплицитног извршавања advice-а. Препоручује се коришћење AOP-а само за инфраструктурне задатке и темељно покривање аспеката тестовима.