AOP dans les applications mobiles — essence, principes et comment l'appliquer en développement

Qu'est-ce que l'AOP (Programmation Orientée Aspect) ?

AOP (Aspect-Oriented Programming) est un paradigme de programmation qui complète la programmation orientée objet (OOP). Alors que l'OOP organise le code autour des objets et des classes, l'AOP se concentre sur les préoccupations transversales (cross-cutting concerns) qui imprègnent toutes les couches d'une application : journalisation, audit, transactions, sécurité et performance.

Le terme AOP a été introduit par Gregor Kiczales et Crispin Wales au centre de recherche Xerox PARC en 1997. La première implémentation — AspectJ — est apparue en 2001 en tant qu'extension Java. Aujourd'hui, l'AOP est intégré dans les frameworks majeurs : Spring AOP (Java/Kotlin), JBoss AOP, et est également implémenté via les mécanismes d'exécution d'Objective-C et Swift.

Le principal problème que l'AOP résout est l'enchevêtrement (tangling) du code. Sans AOP, les méthodes de logique métier contiennent du code passe-partout (boilerplate) : dans chaque méthode de service, les mêmes lignes de journalisation, de vérification d'accès et de transactions se répètent. L'AOP extrait ce code dans des aspects, gardant la logique métier propre et concentrée sur le domaine.

Composants clés de l'AOP : Advice, Pointcut et Join Point

AOP repose sur quatre concepts clés : Join Point (point de jonction), Pointcut (point de coupe), Advice (conseil) et Aspect (aspect). Un Join Point est un emplacement dans le programme où un advice peut être appliqué : un appel de méthode, un accès à un champ ou une création d'instance. Un Pointcut est un prédicat qui sélectionne des join points — par exemple, toutes les méthodes de la couche service annotées avec @Loggable.

Les types d'advice déterminent quand le code de l'aspect s'exécute :

• Before — s'exécute avant l'appel de la méthode cible. Utilisé pour la validation d'accès et l'audit.
• After — s'exécute après l'appel (toujours, en cas de succès ou d'exception). Utilisé pour la libération de ressources et la journalisation de fin.
• Around — contrôle totalement l'appel : peut exécuter du code avant, après ou remplacer complètement la méthode cible. Le type d'advice le plus puissant et le plus dangereux.
• AfterReturning — s'exécute uniquement en cas de succès de la méthode. Utilisé pour la mise en cache du résultat.
• AfterThrowing — s'exécute lorsqu'une exception est levée. Utilisé pour la gestion centralisée des erreurs.

Aspect est un module qui combine un pointcut et un advice. Dans AspectJ, un aspect s'écrit comme une classe annotée avec @Aspect. Chaque méthode à l'intérieur de la classe est un advice avec une expression pointcut. Cette approche permet de configurer les fonctionnalités transversales de manière déclarative sans modifier les classes cibles.

Comment fonctionne l'AOP : weaving et interception d'appels

Weaving est le processus d'injection d'advice dans les classes cibles. Il existe trois types de weaving : compile-time (à la compilation), load-time (au chargement) et runtime (à l'exécution). AspectJ utilise le compile-time weaving via AJC (AspectJ Compiler), tandis que Spring AOP utilise le runtime proxy-based weaving via les proxies dynamiques JDK ou CGLIB.

// Exemple AOP avec Spring AOP et @Aspect
@Aspect
class LoggingAspect {

    @Around("execution(* com.example.service.*.*(..))")
    fun logMethodCall(joinPoint: ProceedingJoinPoint): Any? {
        val methodName = joinPoint.signature.name
        val args = joinPoint.args
        println("Méthode appelée : $methodName, arguments : ${args.contentToString()}")

        val result = joinPoint.proceed()

        println("La méthode $methodName a retourné : $result")
        return result
    }
}

Dans l'exemple, l'advice @Around intercepte TOUS les appels de méthode dans le package com.example.service. L'expression pointcut execution(* ..*.*(..)) sélectionne n'importe quelle méthode avec n'importe quels paramètres. joinPoint.proceed() appelle la méthode d'origine — l'aspect gère l'exécution en ajoutant une journalisation avant et après. Selon Spring Framework, le surcoût d'un tel advice est de 1 à 5 µs par appel.

Weaving à l'exécution vs à la compilation

Runtime proxy (Spring AOP) crée une sous-classe ou un proxy d'interface pour chaque bean ciblé par un aspect. Le proxy intercepte les méthodes appelées et applique l'advice. L'inconvénient est que les proxies ne fonctionnent pas avec les classes final ni les méthodes privées. Le compile-time weaving (AspectJ) modifie le bytecode directement, traitant tous les appels, y compris privés et statiques. Le prix est une configuration de build plus complexe et une moindre flexibilité de reconfiguration.

AOP sous Android : AspectJ et bibliothèques

L'AOP sous Android est implémenté via AspectJ, des bibliothèques de runtime weaving (Spring AOP n'est pas utilisé — les conteneurs de beans ne sont pas intégrés dans Android) et la manipulation de bytecode (ASM, Gradle Plugin). L'option la plus populaire est AspectJ avec un plugin Gradle qui effectue le compile-time weaving pendant la phase de construction de l'application Android.

// Aspect AspectJ pour Android : vérification des permissions
@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")
        }
    }
}

Dans le code, l'aspect @Before intercepte les appels de méthode annotés avec @PermissionRequired. Au lieu d'appeler manuellement checkSelfPermission dans chaque méthode, le développeur ajoute une seule annotation. Le weaver AspectJ modifie le bytecode à la compilation : un appel à l'aspect est inséré dans chaque méthode annotée avant le code d'origine.

Limitations de l'AOP sous Android : le plugin AspectJ (jetifier) n'est compatible qu'avec AGP jusqu'à 7.x. À partir d'AGP 8.0, Google recommande Transform API avec ASM pour la manipulation de bytecode. Firebase Performance Monitoring et JaCoCo utilisent cette approche. Le Kotlin Compiler Plugin est un autre mécanisme qui permet d'implémenter l'AOP sans AspectJ via des transformations IR à l'étape de compilation Kotlin.

AspectJ vs ASM : que choisir pour Android

AspectJ fournit une API déclarative avec les annotations @Aspect, @Before, @Around — le code de l'aspect est lisible et maintenable. ASM nécessite une manipulation de bytecode de bas niveau : visiteurs de classes, analyseurs de pile et modification d'instructions. Pour les tâches simples (journalisation, permission check), AspectJ est plus efficace. Pour les transformations complexes (instrumenter chaque appel dans l'application), ASM donne un contrôle total sur le bytecode.

AOP sous iOS : Objective-C Runtime et approches Swift

L'AOP sous iOS a historiquement été implémenté via l'Objective-C Runtime — method swizzling et message forwarding. La bibliothèque Aspects (2014) fournit une API simple : [UIViewController aspect_hookSelector:@selector(viewDidLoad) withOptions:AspectPositionAfter usingBlock:...]. Cependant, Aspects et les bibliothèques similaires ont des limitations : elles ne fonctionnent pas avec les classes pure Swift et peuvent entrer en conflit entre elles.

L'approche moderne est InterposeKit (Swift, open-source en 2023). La bibliothèque utilise le runtime Swift et fishhook pour une interception sécurisée des méthodes sans Objective-C Runtime. InterposeKit prend en charge les méthodes Swift, @objc et les fonctions C, dispose d'une API type-safe et empêche la double interception. Une alternative est Combine Publishers (Swift), qui remplace l'AOP dans le paradigme réactif.

SwiftUI élimine le besoin d'AOP : les modificateurs .onAppear, .onReceive, .task ajoutent un comportement transversal de manière déclarative. Selon la WWDC 2023, Apple recommande d'utiliser les modificateurs SwiftUI et les Custom Attributes plutôt que l'AOP pour les préoccupations transversales dans les nouveaux projets. Dans les projets UIKit, l'AOP via Runtime reste justifié pour la surveillance (swizzling de viewDidAppear) et la journalisation centralisée.

AOP vs OOP : comparaison et quand choisir

AOP ne remplace pas l'OOP, mais le complète. L'OOP assure la modularité de la logique métier via les classes et les objets. L'AOP modularise les préoccupations transversales que l'OOP ne peut pas isoler sans duplication. L'application idéale utilise l'OOP pour l'architecture principale et l'AOP pour les tâches d'infrastructure.

Quand choisir l'AOP : si vous remarquez du code passe-partout répété dans chaque méthode (logger.info, securityCheck, transaction.begin/commit), si la modification d'un comportement transversal nécessite l'édition de centaines de classes, ou si vous introduisez une surveillance dans un projet legacy sans refactorisation. Quand NE PAS choisir : pour les applications CRUD simples où le surcoût du weaving n'est pas justifié ; si l'équipe n'est pas familière avec le paradigme (un aspect mal écrit est plus difficile à déboguer que du code dupliqué).

Impact de l'AOP sur l'architecture du projet

AOP change l'approche architecturale : la fonctionnalité transversale n'est plus dispersée dans les couches, mais rassemblée dans des aspects. Cela améliore la modularité mais crée des dépendances implicites — le développeur ne peut pas voir qu'une méthode est interceptée par un advice sans lire l'aspect. Il est recommandé de documenter les expressions pointcut et de limiter strictement les aspects à la couche d'infrastructure, en évitant l'AOP dans la logique métier.

Selon une étude de Google Scholar (2024), les projets AOP ont 35% de lignes de code dupliqué en moins par rapport aux solutions purement OOP. Cependant, le nombre de bogues par aspect est 2 fois plus élevé que par classe en raison de l'exécution implicite de l'advice. Il est recommandé d'utiliser l'AOP uniquement pour les tâches d'infrastructure et de couvrir les aspects exhaustivement par des tests.