AOP در برنامه‌های موبایل — ماهیت، اصول و نحوه استفاده در توسعه

AOP (برنامه‌نویسی جنبه‌گرا) چیست؟

AOP (Aspect-Oriented Programming) — پارادایم برنامه‌نویسی است که برنامه‌نویسی شیءگرا (OOP) را تکمیل می‌کند. اگر OOP کد را حول اشیاء و کلاس‌ها سازماندهی می‌کند، AOP وظایف عرضی (cross-cutting concerns) را که در تمام لایه‌های برنامه نفوذ می‌کنند جدا می‌کند: لاگ‌گیری، ممیزی، تراکنش‌ها، امنیت و عملکرد.

اصطلاح AOP توسط گرگور کیچ‌یلز و کریسپین وایکس در مرکز تحقیقاتی Xerox PARC در سال ۱۹۹۷ معرفی شد. اولین پیاده‌سازی — AspectJ — در سال ۲۰۰۱ به عنوان افزونه جاوا ظاهر شد. امروزه AOP در بزرگترین فریم‌ورک‌ها تعبیه شده است: Spring AOP (Java/Kotlin)، JBoss AOP، همچنین از طریق مکانیسم‌های زمان اجرای Objective-C و Swift پیاده‌سازی می‌شود.

مشکل اصلی که AOP حل می‌کند — درهم‌تنیدگی (tangling) کد است. بدون AOP، متدهای منطق کسب‌وکار حاوی کدهای تکراری هستند: در هر متد سرویس، همان خطوط لاگ‌گیری، بررسی دسترسی و تراکنش‌ها تکرار می‌شوند. 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، جنبه به صورت کلاسی با annotation @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
    }
}

در مثال، advice @Around تمام فراخوانی‌های متد را در بسته com.example.service قطع می‌کند. عبارت pointcut execution(* ..*.*(..)) هر متدی با هر پارامتری را انتخاب می‌کند. joinPoint.proceed() متد اصلی را فراخوانی می‌کند — جنبه اجرا را مدیریت می‌کند و لاگ‌گیری را قبل و بعد اضافه می‌کند. به گفته Spring Framework، سربار چنین advice ۱–۵ میکروثانیه به ازای هر فراخوانی است.

Runtime در مقابل compile-time weaving

Proxy زمان اجرا (Spring AOP) برای هر بین (bean) که جنبه به آن هدف گرفته، یک زیرکلاس یا پروکسی واسط ایجاد می‌کند. پروکسی متدهای فراخوانی‌شده را قطع کرده و advice اعمال می‌کند. ضعف — پروکسی با کلاس‌های final و متدهای خصوصی کار نمی‌کند. Compile-time weaving (AspectJ) بایت‌کد را مستقیماً تغییر می‌دهد و تمام فراخوانی‌ها از جمله خصوصی و ایستا را پردازش می‌کند. بهای آن — پیکربندی ساخت پیچیده‌تر و انعطاف‌پذیری کمتر در بازپیکربندی.

AOP در Android: AspectJ و کتابخانه‌ها

AOP در Android از طریق AspectJ، کتابخانه‌های runtime weaving (Spring AOP استفاده نمی‌شود — کانتینرهای بین در Android تعبیه نشده‌اند) و bytecode manipulation (ASM, Gradle Plugin) پیاده‌سازی می‌شود. محبوب‌ترین گزینه — AspectJ با پلاگین Gradle که در مرحله ساخت برنامه Android compile-time weaving را انجام می‌دهد.

// جنبه 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 فراخوانی‌های متدهای با annotation @PermissionRequired را قطع می‌کند. به جای فراخوانی دستی checkSelfPermission در هر متد، توسعه‌دهنده یک annotation اضافه می‌کند. AspectJ weaver در مرحله کامپایل بایت‌کد را تغییر می‌دهد: در هر متد دارای annotation، فراخوانی جنبه قبل از کد اصلی درج می‌شود.

محدودیت‌های AOP در Android: پلاگین AspectJ (jetifier) فقط با AGP تا نسخه ۷.x سازگار است. از AGP 8.0، Google Transform API را با ASM برای bytecode manipulation توصیه می‌کند. Firebase Performance Monitoring و JaCoCo دقیقاً از این رویکرد استفاده می‌کنند. Kotlin Compiler Plugin — مکانیسم دیگری است که امکان پیاده‌سازی AOP بدون AspectJ را از طریق IR-transform در مرحله کامپایل Kotlin فراهم می‌کند.

AspectJ در مقابل ASM: چه چیزی برای Android انتخاب کنیم

AspectJ API اعلامی با annotation‌های @Aspect، @Before، @Around ارائه می‌دهد — کد جنبه خوانا و قابل نگهداری است. ASM نیاز به کار سطح پایین با بایت‌کد دارد: بازدیدکنندگان کلاس، تحلیل‌گرهای پشته و تغییر دستورالعمل‌ها. برای کارهای ساده (لاگ‌گیری، بررسی مجوز) AspectJ مؤثرتر است. برای تبدیل‌های پیچیده (instrumentation هر فراخوانی در برنامه) ASM کنترل کامل بر بایت‌کد می‌دهد.

AOP در iOS: Objective-C Runtime و رویکردهای Swift

AOP در iOS از نظر تاریخی از طریق Objective-C Runtime — method swizzling و message forwarding پیاده‌سازی می‌شود. کتابخانه Aspects (۲۰۱۴) API ساده‌ای ارائه می‌دهد: [UIViewController aspect_hookSelector:@selector(viewDidLoad) withOptions:AspectPositionAfter usingBlock:...]. اما Aspects و کتابخانه‌های مشابه محدودیت‌هایی دارند: با کلاس‌های pure Swift کار نمی‌کنند و ممکن است با یکدیگر تداخل داشته باشند.

رویکرد مدرن — InterposeKit (Swift، منبع باز در ۲۰۲۳). این کتابخانه از Swift runtime و fishhook برای قطع ایمن متدها بدون Objective-C Runtime استفاده می‌کند. InterposeKit از متدهای Swift، @objc و توابع C پشتیبانی می‌کند، API نوع-ایمن دارد و از قطع مضاعف جلوگیری می‌کند. جایگزین — Combine Publishers (Swift) که AOP را در پارادایم واکنشی جایگزین می‌کنند.

SwiftUI نیاز به AOP را برطرف می‌کند: اصلاح‌کننده‌های .onAppear، .onReceive، .task رفتار عرضی را به صورت اعلامی اضافه می‌کنند. به گفته WWDC 2023، Apple استفاده از اصلاح‌کننده‌های SwiftUI و Custom Attributes را به جای AOP برای concerns عرضی در پروژه‌های جدید توصیه می‌کند. در پروژه‌های UIKit، AOP از طریق Runtime برای نظارت (swizzling viewDidAppear) و لاگ‌گیری متمرکز همچنان موجه است.

AOP در مقابل OOP: مقایسه و زمان انتخاب

AOP جایگزین OOP نمی‌شود، بلکه آن را تکمیل می‌کند. OOP ماژولاریت منطق کسب‌وکار را از طریق کلاس‌ها و اشیاء فراهم می‌کند. AOP concerns عرضی را که OOP بدون تکرار نمی‌تواند جدا کند، ماژولاریزه می‌کند. برنامه ایده‌آل از OOP برای معماری اصلی و از AOP برای وظایف زیرساختی استفاده می‌کند.

چه زمانی AOP را انتخاب کنیم: اگر کد تکراری در هر متد مشاهده می‌کنید (logger.info, securityCheck, transaction.begin/commit)، اگر تغییر رفتار عرضی نیاز به ویرایش صدها کلاس دارد، اگر نظارت را در پروژه legacy بدون بازسازی اعمال می‌کنید. چه زمانی انتخاب نکنیم: برای برنامه‌های ساده CRUD که سربار weaving توجیه ندارد؛ اگر تیم با پارادایم آشنایی کمی دارد (جنبه بد نوشته شده از کد تکراری سخت‌تر اشکال‌زدایی می‌شود).

تأثیر AOP بر معماری پروژه

AOP رویکرد معماری را تغییر می‌دهد: قابلیت‌های عرضی دیگر در لایه‌ها پخش نیستند، بلکه در جنبه‌ها جمع می‌شوند. این کار ماژولاریت را بهبود می‌بخشد، اما وابستگی‌های ضمنی ایجاد می‌کند — توسعه‌دهنده بدون خواندن جنبه نمی‌بیند که متد توسط advice قطع می‌شود. توصیه می‌شود عبارات pointcut مستندسازی شود و جنبه‌ها strictly به لایه زیرساختی محدود شوند، بدون اعمال AOP به منطق کسب‌وکار.

بر اساس تحقیق Google Scholar (۲۰۲۴)، پروژه‌های AOP ۳۵٪ خطوط کد تکراری کمتری نسبت به راه‌حل‌های خالص OOP دارند. با این حال، تعداد باگ‌ها به ازای هر جنبه ۲ برابر بیشتر از هر کلاس است، به دلیل اجرای ضمنی advice. توصیه می‌شود AOP فقط برای وظایف زیرساختی استفاده شود و جنبه‌ها به طور کامل با تست پوشش داده شوند.