Mobil Uygulamalarda AOP — Özü, İlkeleri ve Geliştirmede Nasıl Uygulanacağı

AOP (Yönelim Odaklı Programlama) Nedir?

AOP (Aspect-Oriented Programming), nesne yönelimli programlamayı (OOP) tamamlayan bir programlama paradigmasıdır. OOP kodu nesneler ve sınıflar etrafında düzenlerken, AOP bir uygulamanın tüm katmanlarını etkileyen kesişen endişelere (günlükleme, denetim, işlemler, güvenlik ve performans) odaklanır.

AOP terimi, 1997 yılında Xerox PARC araştırma merkezinde Gregor Kiczales ve Crispin Wales tarafından tanıtıldı. İlk uygulama — AspectJ — 2001 yılında bir Java uzantısı olarak ortaya çıktı. Bugün AOP, büyük çerçevelere (Spring AOP (Java/Kotlin), JBoss AOP) entegre edilmiştir ve ayrıca Objective-C ve Swift çalışma zamanı mekanizmaları aracılığıyla da uygulanmaktadır.

AOP'nin çözdüğü ana sorun, kodun dolanıklığı (tangling)dır. AOP olmadan, iş mantığı yöntemleri tekrar eden kod (boilerplate) içerir: her hizmet yönteminde aynı günlükleme, erişim kontrolü ve işlem satırları tekrarlanır. AOP bu kodu yönelimlere çıkararak iş mantığını temiz ve alana odaklı tutar.

AOP'nin Temel Bileşenleri: Advice, Pointcut ve Join Point

AOP dört temel kavram üzerine inşa edilmiştir: Join Point (birleşim noktası), Pointcut (kesim noktası), Advice (tavsiye) ve Aspect (yönelim). Join Point, programda advice'in uygulanabileceği bir konumdur: bir yöntem çağrısı, alan erişimi veya örnek oluşturma. Pointcut, join point'leri seçen bir yüklemdir — örneğin, @Loggable ile işaretlenmiş tüm hizmet katmanı yöntemleri.

Advice türleri, yönelim kodunun ne zaman yürütüleceğini belirler:

• Before — hedef yöntem çağrısından önce yürütülür. Erişim doğrulaması ve denetim için kullanılır.
• After — çağrıdan sonra yürütülür (her zaman, başarılı veya istisna durumunda). Kaynak serbest bırakma ve tamamlama günlüklemesi için kullanılır.
• Around — çağrıyı tamamen kontrol eder: kodu öncesinde, sonrasında yürütebilir veya hedef yöntemi tamamen değiştirebilir. En güçlü ve en tehlikeli advice türüdür.
• AfterReturning — yalnızca yöntem başarıyla tamamlandığında yürütülür. Sonucu önbelleğe almak için kullanılır.
• AfterThrowing — bir istisna atıldığında yürütülür. Merkezi hata işleme için kullanılır.

Aspect, pointcut ve advice'i birleştiren bir modüldür. AspectJ'de bir yönelim, @Aspect ile işaretlenmiş bir sınıf olarak yazılır. Sınıf içindeki her yöntem, bir pointcut ifadesine sahip bir advice'dir. Bu yaklaşım, hedef sınıfları değiştirmeden kesişen işlevselliği bildirimsel olarak yapılandırmaya olanak tanır.

AOP Nasıl Çalışır: Weaving ve Çağrı Kesme

Weaving, advice'i hedef sınıflara enjekte etme sürecidir. Üç tür weaving vardır: derleme zamanı (compile-time), yükleme zamanı (load-time) ve çalışma zamanı (runtime). AspectJ, AJC (AspectJ Compiler) aracılığıyla derleme zamanı weaving kullanırken, Spring AOP, JDK dinamik proxy'leri veya CGLIB aracılığıyla çalışma zamanı proxy tabanlı weaving kullanır.

// Spring AOP ve @Aspect ile AOP Örneği
@Aspect
class LoggingAspect {

    @Around("execution(* com.example.service.*.*(..))")
    fun logMethodCall(joinPoint: ProceedingJoinPoint): Any? {
        val methodName = joinPoint.signature.name
        val args = joinPoint.args
        println("Yöntem çağrıldı: $methodName, argümanlar: ${args.contentToString()}")

        val result = joinPoint.proceed()

        println("$methodName yöntemi döndürdü: $result")
        return result
    }
}

Örnekte, @Around advice, com.example.service paketindeki TÜM yöntem çağrılarını keser. execution(* ..*.*(..)) pointcut ifadesi, herhangi bir parametreye sahip herhangi bir yöntemi seçer. joinPoint.proceed() orijinal yöntemi çağırır — yönelim, öncesine ve sonrasına günlükleme ekleyerek yürütmeyi yönetir. Spring Framework'e göre, böyle bir advice'in ek yükü (overhead) çağrı başına 1–5 µs'dir.

Çalışma Zamanı vs Derleme Zamanı Weaving

Runtime proxy (Spring AOP), bir yönelim tarafından hedeflenen her bean için bir alt sınıf veya arayüz proxy'si oluşturur. Proxy, çağrılan yöntemleri keser ve advice'i uygular. Dezavantajı, proxy'lerin final sınıfları ve private yöntemlerle çalışmamasıdır. Derleme zamanı weaving (AspectJ), bytecode'u doğrudan değiştirir, private ve static dahil tüm çağrıları işler. Bunun bedeli daha karmaşık derleme yapılandırması ve daha düşük yeniden yapılandırma esnekliğidir.

Android'de AOP: AspectJ ve Kütüphaneler

Android'de AOP, AspectJ, çalışma zamanı weaving kütüphaneleri (Spring AOP kullanılmaz — bean konteynırları Android'e entegre değildir) ve bytecode manipülasyonu (ASM, Gradle Plugin) aracılığıyla uygulanır. En popüler seçenek, Android uygulaması derleme aşamasında derleme zamanı weaving gerçekleştiren bir Gradle eklentisi ile AspectJ'dir.

// Android için AspectJ yönelimi: izin kontrolü
@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 yönelimi, @PermissionRequired ile işaretlenmiş yöntem çağrılarını keser. Geliştirici, her yöntemde manuel olarak checkSelfPermission çağırmak yerine tek bir ekleme (annotasyon) yapar. AspectJ weaver, derleme zamanında bytecode'u değiştirir: orijinal koddan önce, işaretlenmiş her yönteme bir yönelim çağrısı eklenir.

Android'de AOP'nin sınırlamaları: AspectJ eklentisi (jetifier) yalnızca AGP 7.x'e kadar uyumludur. AGP 8.0'den itibaren Google, bytecode manipülasyonu için Transform API'yi ASM ile birlikte önermektedir. Firebase Performance Monitoring ve JaCoCo bu yaklaşımı kullanır. Kotlin Compiler Plugin, Kotlin derleme aşamasında IR dönüşümleri aracılığıyla AspectJ olmadan AOP'yi mümkün kılan başka bir mekanizmadır.

AspectJ vs ASM: Android İçin Ne Seçilmeli

AspectJ, @Aspect, @Before, @Around eklemeleriyle bildirimsel bir API sağlar — yönelim kodu okunabilir ve bakımı yapılabilir. ASM, düşük seviyeli bytecode manipülasyonu gerektirir: sınıf ziyaretçileri, yığın analizörleri ve talimat değişikliği. Basit görevler (günlükleme, permission check) için AspectJ daha verimlidir. Karmaşık dönüşümler (uygulamadaki her çağrıyı enstrümante etme) için ASM, bytecode üzerinde tam kontrol sağlar.

iOS'te AOP: Objective-C Runtime ve Swift Yaklaşımları

iOS'te AOP tarihsel olarak Objective-C Runtime — method swizzling ve message forwarding — aracılığıyla uygulanmıştır. Aspects kütüphanesi (2014) basit bir API sağlar: [UIViewController aspect_hookSelector:@selector(viewDidLoad) withOptions:AspectPositionAfter usingBlock:...]. Ancak Aspects ve benzer kütüphanelerin sınırlamaları vardır: saf Swift sınıflarıyla çalışmazlar ve birbirleriyle çelişebilirler.

Modern yaklaşım InterposeKit'tir (Swift, 2023'te açık kaynak). Kütüphane, Objective-C Runtime olmadan güvenli yöntem kesmesi için Swift runtime ve fishhook kullanır. InterposeKit, Swift yöntemlerini, @objc'yi ve C işlevlerini destekler, tür güvenli bir API'ye sahiptir ve çift kesmeyi önler. Bir alternatif, reaktif paradigmada AOP'nin yerini alan Combine Publishers'dır (Swift).

SwiftUI, AOP ihtiyacını ortadan kaldırır: .onAppear, .onReceive, .task değiştiricileri bildirimsel olarak kesişen davranış ekler. WWDC 2023'e göre Apple, yeni projelerde kesişen endişeler için AOP yerine SwiftUI değiştiricileri ve Custom Attributes kullanılmasını önermektedir. UIKit projelerinde, Runtime aracılığıyla AOP, izleme (viewDidAppear swizzling) ve merkezi günlükleme için haklı kalmaya devam etmektedir.

AOP vs OOP: Karşılaştırma ve Ne Zaman Seçilmeli

AOP OOP'yi değiştirmez, onu tamamlar. OOP, sınıflar ve nesneler aracılığıyla iş mantığının modülerliğini sağlar. AOP, OOP'nin tekrarsız ayıramadığı kesişen endişeleri modülerleştirir. İdeal uygulama, ana mimari için OOP'yi ve altyapı görevleri için AOP'yi kullanır.

AOP ne zaman seçilmeli: her yöntemde tekrarlanan kod (logger.info, securityCheck, transaction.begin/commit) fark ediyorsanız, kesişen davranışı değiştirmek yüzlerce sınıfı düzenlemeyi gerektiriyorsa veya yeniden düzenleme yapmadan eski bir projeye izleme ekliyorsanız. Ne zaman SEÇİLMEMELİ: basit CRUD uygulamaları için weaving ek yükü haklı değilse; ekip paradigmaya aşina değilse (kötü yazılmış bir yönelim, tekrarlanan koddan daha zor hata ayıklanır).

AOP'nin Proje Mimarisi Üzerindeki Etkisi

AOP mimari yaklaşımı değiştirir: kesişen işlevsellik artık katmanlara dağılmış değil, yönelimlerde toplanmıştır. Bu modülerliği iyileştirir ancak örtük bağımlılıklar oluşturur — geliştirici, yönelimi okumadan bir yöntemin advice tarafından kesildiğini göremez. Pointcut ifadelerinin belgelenmesi ve yönelimlerin kesinlikle altyapı katmanıyla sınırlandırılması, iş mantığında AOP'den kaçınılması önerilir.

Google Scholar araştırmasına (2024) göre, AOP projeleri saf OOP çözümlerine kıyasla %35 daha az tekrarlanan kod satırına sahiptir. Ancak, advice'in örtük yürütülmesi nedeniyle yönelim başına hata sayısı sınıf başına 2 kat daha fazladır. AOP'nin yalnızca altyapı görevleri için kullanılması ve yönelimlerin testlerle kapsamlı bir şekilde kaplanması önerilir.