موبائل ایپلیکیشنز میں AOP — جوہر، اصول اور ڈیولپمنٹ میں کیسے استعمال کریں

AOP (اسپیکٹ اورینٹڈ پروگرامنگ) کیا ہے؟

AOP (Aspect-Oriented Programming) ایک پروگرامنگ نمونہ ہے جو آبجیکٹ اورینٹڈ پروگرامنگ (OOP) کی تکمیل کرتا ہے۔ جہاں OOP کوڈ کو آبجیکٹس اور کلاسز کے ارد گرد منظم کرتا ہے، وہاں AOP کراس کٹنگ خدشات (cross-cutting concerns) پر توجہ مرکوز کرتا ہے جو ایپلیکیشن کی تمام تہوں میں پھیلے ہوتے ہیں: لاگنگ، آڈیٹنگ، لین دین، سکیورٹی اور کارکردگی۔

AOP کی اصطلاح 1997 میں Xerox PARC تحقیقی مرکز میں Gregor Kiczales اور Crispin Wales نے متعارف کروائی تھی۔ پہلا نفاذ — AspectJ — 2001 میں Java ایکسٹینشن کے طور پر سامنے آیا۔ آج AOP بڑے فریم ورکس میں شامل ہے: Spring AOP (Java/Kotlin)، JBoss AOP، اور Objective-C اور Swift رن ٹائم میکانزم کے ذریعے بھی لاگو کیا گیا ہے۔

AOP جس اہم مسئلے کو حل کرتا ہے وہ کوڈ کی الجھن (tangling) ہے۔ AOP کے بغیر، کاروباری منطق کے طریقوں میں boilerplate کوڈ ہوتا ہے: ہر سروس طریقہ کار میں لاگنگ، رسائی کی جانچ اور لین دین کی ایک جیسی سطریں دہرائی جاتی ہیں۔ AOP اس کوڈ کو اسپیکٹس میں نکالتا ہے، کاروباری منطق کو صاف اور ڈومین پر مرکوز رکھتا ہے۔

AOP کے اہم اجزاء: Advice، Pointcut اور Join Point

AOP چار اہم تصورات پر بنایا گیا ہے: Join Point (جوائن پوائنٹ)، Pointcut (پوائنٹ کٹ)، Advice (ایڈوائس) اور Aspect (اسپیکٹ)۔ Join Point پروگرام میں وہ مقام ہے جہاں advice لاگو کیا جا سکتا ہے: ایک طریقہ کال، فیلڈ تک رسائی، یا مثال کی تخلیق۔ Pointcut ایک پیش گوئی ہے جو join points کا انتخاب کرتی ہے — مثال کے طور پر، @Loggable سے مزین تمام سروس پرت کے طریقے۔

Advice کی اقسام یہ طے کرتی ہیں کہ اسپیکٹ کوڈ کب عمل میں آتا ہے:

• Before — ہدف کے طریقہ کار کی کال سے پہلے عمل میں آتا ہے۔ رسائی کی توثیق اور آڈیٹنگ کے لیے استعمال ہوتا ہے۔
• After — کال کے بعد عمل میں آتا ہے (ہمیشہ، کامیابی پر یا استثنا پر)۔ وسائل کی رہائی اور تکمیل کی لاگنگ کے لیے استعمال ہوتا ہے۔
• Around — کال کو مکمل طور پر کنٹرول کرتا ہے: کوڈ کو پہلے، بعد میں لاگو کر سکتا ہے یا ہدف کے طریقہ کار کو مکمل طور پر تبدیل کر سکتا ہے۔ سب سے طاقتور اور خطرناک قسم کا advice۔
• AfterReturning — صرف طریقہ کار کے کامیابی سے مکمل ہونے پر عمل میں آتا ہے۔ نتیجہ کیش کرنے کے لیے استعمال ہوتا ہے۔
• AfterThrowing — جب استثنا پھینکا جاتا ہے تو عمل میں آتا ہے۔ مرکزی خرابی سے نمٹنے کے لیے استعمال ہوتا ہے۔

Aspect ایک ماڈیول ہے جو pointcut اور advice کو یکجا کرتا ہے۔ AspectJ میں، اسپیکٹ @Aspect سے مزین کلاس کے طور پر لکھا جاتا ہے۔ کلاس کے اندر ہر طریقہ کار pointcut اظہار کے ساتھ ایک advice ہے۔ یہ طریقہ ہدف کلاسز میں ترمیم کیے بغیر کراس کٹنگ فعالیت کو اعلانیہ طور پر ترتیب دینے کی اجازت دیتا ہے۔

AOP کیسے کام کرتا ہے: weaving اور کال مداخلت

Weaving ہدف کلاسز میں advice داخل کرنے کا عمل ہے۔ weaving کی تین اقسام ہیں: compile-time (ترجمہ وقت)، load-time (لوڈ وقت) اور runtime (چلنے کا وقت)۔ AspectJ AJC (AspectJ Compiler) کے ذریعے compile-time weaving استعمال کرتا ہے، جبکہ Spring AOP JDK ڈائنامک پراکسی یا CGLIB کے ذریعے runtime proxy-based weaving استعمال کرتا ہے۔

// Spring AOP اور @Aspect کے ساتھ AOP مثال
@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 کے مطابق، اس طرح کے advice کا اوور ہیڈ 1–5 µs فی کال ہے۔

رن ٹائم بمقابلہ کمپائل ٹائم weaving

Runtime proxy (Spring AOP) اسپیکٹ کے ہدف والے ہر بین کے لیے ایک ذیلی کلاس یا انٹرفیس پراکسی بناتا ہے۔ پراکسی کال کیے گئے طریقوں کو روکتا ہے اور advice لاگو کرتا ہے۔ نقصان یہ ہے کہ پراکسی final کلاسز اور private طریقوں کے ساتھ کام نہیں کرتی۔ Compile-time weaving (AspectJ) براہ راست بائٹ کوڈ میں ترمیم کرتا ہے، private اور static سمیت تمام کالز کو ہینڈل کرتا ہے۔ اس کی قیمت زیادہ پیچیدہ بلڈ کنفیگریشن اور کم دوبارہ ترتیب لچک ہے۔

Android میں AOP: AspectJ اور لائبریریاں

Android پر AOP AspectJ، runtime weaving لائبریریوں (Spring AOP استعمال نہیں کیا جاتا — بین کنٹینر Android میں شامل نہیں ہیں) اور بائٹ کوڈ مینیپولیشن (ASM، Gradle Plugin) کے ذریعے لاگو کیا جاتا ہے۔ سب سے مشہور آپشن Gradle پلگ ان کے ساتھ AspectJ ہے جو Android ایپ بلڈ مرحلے کے دوران compile-time weaving انجام دیتا ہے۔

// Android کے لیے AspectJ اسپیکٹ: اجازت کی جانچ
@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 ترجمہ وقت پر بائٹ کوڈ میں ترمیم کرتا ہے: اصل کوڈ سے پہلے ہر مزین طریقہ کار میں ایک اسپیکٹ کال داخل کی جاتی ہے۔

Android پر AOP کی حدود: AspectJ پلگ ان (jetifier) صرف AGP 7.x تک ہم آہنگ ہے۔ AGP 8.0 سے شروع کرتے ہوئے، Google بائٹ کوڈ مینیپولیشن کے لیے Transform API کو ASM کے ساتھ تجویز کرتا ہے۔ Firebase Performance Monitoring اور JaCoCo اس طریقہ کو استعمال کرتے ہیں۔ Kotlin Compiler Plugin ایک اور میکانزم ہے جو Kotlin ترجمہ مرحلے میں IR تبدیلیوں کے ذریعے AspectJ کے بغیر AOP کو قابل بناتا ہے۔

AspectJ بمقابلہ ASM: Android کے لیے کیا منتخب کریں

AspectJ @Aspect، @Before، @Around اعلانات کے ساتھ ایک اعلانیہ API فراہم کرتا ہے — اسپیکٹ کوڈ پڑھنے کے قابل اور برقرار رکھنے کے قابل ہے۔ ASM کے لیے نچلی سطح کی بائٹ کوڈ مینیپولیشن کی ضرورت ہوتی ہے: کلاس وزیٹر، اسٹیک تجزیہ کار اور ہدایات میں ترمیم۔ سادہ کاموں (لاگنگ، permission check) کے لیے AspectJ زیادہ کارآمد ہے۔ پیچیدہ تبدیلیوں (ایپلیکیشن میں ہر کال کو آلہ بند کرنا) کے لیے ASM بائٹ کوڈ پر مکمل کنٹرول دیتا ہے۔

iOS میں AOP: Objective-C Runtime اور Swift طریقے

iOS پر AOP تاریخی طور پر Objective-C Runtime — method swizzling اور message forwarding کے ذریعے لاگو کیا گیا ہے۔ Aspects لائبریری (2014) ایک سادہ API فراہم کرتی ہے: [UIViewController aspect_hookSelector:@selector(viewDidLoad) withOptions:AspectPositionAfter usingBlock:...]۔ تاہم، Aspects اور اسی طرح کی لائبریریوں کی حدود ہیں: وہ خالص Swift کلاسز کے ساتھ کام نہیں کرتیں اور ایک دوسرے سے متصادم ہو سکتی ہیں۔

جدید طریقہ InterposeKit ہے (Swift، 2023 میں اوپن سورس)۔ لائبریری Objective-C Runtime کے بغیر محفوظ طریقہ کار مداخلت کے لیے Swift runtime اور fishhook استعمال کرتی ہے۔ InterposeKit Swift طریقوں، @objc اور C فنکشنز کو سپورٹ کرتی ہے، ٹائپ سیف API رکھتی ہے اور دوہری مداخلت کو روکتی ہے۔ ایک متبادل Combine Publishers (Swift) ہے جو ری ایکٹیو نمونے میں AOP کی جگہ لیتا ہے۔

SwiftUI AOP کی ضرورت کو ختم کرتا ہے: .onAppear، .onReceive، .task موڈیفائر اعلانیہ طور پر کراس کٹنگ رویہ شامل کرتے ہیں۔ WWDC 2023 کے مطابق، Apple نئے پروجیکٹس میں کراس کٹنگ خدشات کے لیے AOP کے بجائے SwiftUI موڈیفائر اور Custom Attributes استعمال کرنے کی تجویز کرتا ہے۔ UIKit پروجیکٹس میں، Runtime کے ذریعے AOP نگرانی (viewDidAppear swizzling) اور مرکزی لاگنگ کے لیے جائز رہتا ہے۔

AOP بمقابلہ OOP: موازنہ اور کب انتخاب کریں

AOP OOP کو تبدیل نہیں کرتا بلکہ اس کی تکمیل کرتا ہے۔ OOP کلاسز اور آبجیکٹس کے ذریعے کاروباری منطق کی ماڈیولریٹی فراہم کرتا ہے۔ AOP کراس کٹنگ خدشات کو ماڈیولرائز کرتا ہے جنہیں OOP تکرار کے بغیر الگ نہیں کر سکتا۔ مثالی ایپلیکیشن مرکزی فن تعمیر کے لیے OOP اور بنیادی ڈھانچے کے کاموں کے لیے AOP استعمال کرتی ہے۔

AOP کب منتخب کریں: اگر آپ ہر طریقہ کار میں بار بار آنے والا boilerplate کوڈ (logger.info, securityCheck, transaction.begin/commit) دیکھتے ہیں، اگر کراس کٹنگ رویے کو تبدیل کرنے کے لیے سینکڑوں کلاسز میں ترمیم کی ضرورت ہو، یا اگر آپ ری فیکٹرنگ کے بغیر کسی پرانے پروجیکٹ میں نگرانی متعارف کروا رہے ہیں۔ کب منتخب نہ کریں: سادہ CRUD ایپلیکیشنز کے لیے جہاں weaving کا اوور ہیڈ جائز نہیں؛ اگر ٹیم نمونے سے واقف نہیں ہے (بری طرح لکھا گیا اسپیکٹ ڈیبگ کرنے میں نقل شدہ کوڈ سے زیادہ مشکل ہوتا ہے)۔

پروجیکٹ کے فن تعمیر پر AOP کا اثر

AOP فن تعمیراتی طریقہ کو بدلتا ہے: کراس کٹنگ فعالیت اب تہوں میں بکھری نہیں ہے بلکہ اسپیکٹس میں جمع ہے۔ یہ ماڈیولریٹی کو بہتر بناتا ہے لیکن پوشیدہ انحصاریاں پیدا کرتا ہے — ڈویلپر اسپیکٹ کو پڑھے بغیر نہیں دیکھ سکتا کہ کوئی طریقہ advice کے ذریعے روکا جا رہا ہے۔ pointcut اظہارات کو دستاویز کرنے اور اسپیکٹس کو سختی سے بنیادی ڈھانچے کی تہہ تک محدود رکھنے کی سفارش کی جاتی ہے، کاروباری منطق میں AOP سے گریز کرتے ہوئے۔

Google Scholar (2024) کے ایک مطالعے کے مطابق، AOP پروجیکٹس میں خالص OOP حل کے مقابلے میں 35% کم نقل شدہ کوڈ لائنیں ہوتی ہیں۔ تاہم، advice کے پوشیدہ عمل درآمد کی وجہ سے فی اسپیکٹ خرابیوں کی تعداد فی کلاس سے 2 گنا زیادہ ہوتی ہے۔ AOP صرف بنیادی ڈھانچے کے کاموں کے لیے استعمال کرنے اور اسپیکٹس کو ٹیسٹوں سے اچھی طرح ڈھانپنے کی سفارش کی جاتی ہے۔