AOP em aplicações móveis — essência, princípios e como aplicar no desenvolvimento

O que é AOP (Programação Orientada a Aspectos)?

AOP (Aspect-Oriented Programming) é um paradigma de programação que complementa a programação orientada a objetos (OOP). Enquanto OOP organiza o código em torno de objetos e classes, AOP foca em preocupações transversais (cross-cutting concerns) que permeiam todas as camadas de uma aplicação: logging, auditoria, transações, segurança e desempenho.

O termo AOP foi introduzido por Gregor Kiczales e Crispin Wales no centro de pesquisa Xerox PARC em 1997. A primeira implementação — AspectJ — surgiu em 2001 como uma extensão Java. Hoje, AOP está integrado nos principais frameworks: Spring AOP (Java/Kotlin), JBoss AOP, e também é implementado através de mecanismos runtime de Objective-C e Swift.

O principal problema que AOP resolve é o emaranhamento (tangling) do código. Sem AOP, os métodos de lógica de negócio contêm boilerplate: em cada método de serviço, repetem-se as mesmas linhas de logging, verificação de acesso e transações. AOP extrai esse código para aspectos, mantendo a lógica de negócio limpa e focada no domínio.

Componentes-chave do AOP: Advice, Pointcut e Join Point

AOP é construído sobre quatro conceitos-chave: Join Point (ponto de junção), Pointcut (corte), Advice (conselho) e Aspect (aspeto). Um Join Point é um local no programa onde um advice pode ser aplicado: uma chamada de método, acesso a campo ou criação de instância. Um Pointcut é um predicado que seleciona join points — por exemplo, todos os métodos da camada de serviço anotados com @Loggable.

Os tipos de advice determinam quando o código do aspeto é executado:

• Before — executa antes da chamada do método alvo. Usado para validação de acesso e auditoria.
• After — executa após a chamada (sempre, com sucesso ou com exceção). Usado para libertação de recursos e logging de conclusão.
• Around — controla totalmente a chamada: pode executar código antes, depois ou substituir completamente o método alvo. O tipo de advice mais poderoso e perigoso.
• AfterReturning — executa apenas quando o método é concluído com sucesso. Usado para armazenar em cache o resultado.
• AfterThrowing — executa quando uma exceção é lançada. Usado para tratamento centralizado de erros.

Aspect é um módulo que combina um pointcut e um advice. No AspectJ, um aspeto é escrito como uma classe anotada com @Aspect. Cada método dentro da classe é um advice com uma expressão pointcut. Esta abordagem permite configurar funcionalidades transversais declarativamente sem modificar as classes alvo.

Como funciona o AOP: weaving e intercepção de chamadas

Weaving é o processo de injetar advice nas classes alvo. Existem três tipos de weaving: compile-time (tempo de compilação), load-time (tempo de carga) e runtime (tempo de execução). AspectJ usa compile-time weaving através do AJC (AspectJ Compiler), enquanto Spring AOP usa runtime proxy-based weaving através de proxies dinâmicos JDK ou CGLIB.

// Exemplo AOP com Spring AOP e @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étodo chamado: $methodName, argumentos: ${args.contentToString()}")

        val result = joinPoint.proceed()

        println("Método $methodName retornou: $result")
        return result
    }
}

No exemplo, o advice @Around intercepta TODAS as chamadas de método no pacote com.example.service. A expressão pointcut execution(* ..*.*(..)) seleciona qualquer método com quaisquer parâmetros. joinPoint.proceed() chama o método original — o aspeto gerencia a execução adicionando logging antes e depois. De acordo com o Spring Framework, a sobrecarga desse advice é de 1 a 5 µs por chamada.

Weaving em tempo de execução vs compilação

Runtime proxy (Spring AOP) cria uma subclasse ou proxy de interface para cada bean alvo do aspeto. O proxy intercepta os métodos chamados e aplica o advice. A desvantagem é que proxies não funcionam com classes final nem métodos privados. O compile-time weaving (AspectJ) modifica o bytecode diretamente, lidando com todas as chamadas, incluindo privadas e estáticas. A contrapartida é uma configuração de compilação mais complexa e menor flexibilidade de reconfiguração.

AOP no Android: AspectJ e bibliotecas

AOP no Android é implementado através de AspectJ, bibliotecas de runtime weaving (Spring AOP não é usado — contentores de beans não estão integrados no Android) e manipulação de bytecode (ASM, Gradle Plugin). A opção mais popular é AspectJ com um plugin Gradle que realiza compile-time weaving durante a compilação da aplicação Android.

// Aspeto AspectJ para Android: permission check
@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")
        }
    }
}

No código, o aspeto @Before intercepta chamadas de método anotadas com @PermissionRequired. Em vez de chamar manualmente checkSelfPermission em cada método, o desenvolvedor adiciona uma única anotação. O weaver do AspectJ modifica o bytecode em tempo de compilação: uma chamada ao aspeto é inserida em cada método anotado antes do código original.

Limitações do AOP no Android: o plugin AspectJ (jetifier) é compatível apenas com AGP até 7.x. A partir do AGP 8.0, a Google recomenda Transform API com ASM para manipulação de bytecode. Firebase Performance Monitoring e JaCoCo usam esta abordagem. O Kotlin Compiler Plugin é outro mecanismo que permite implementar AOP sem AspectJ através de transformações IR na fase de compilação Kotlin.

AspectJ vs ASM: o que escolher para Android

AspectJ fornece uma API declarativa com anotações @Aspect, @Before, @Around — o código do aspeto é legível e mantível. ASM requer manipulação de bytecode de baixo nível: visitantes de classes, analisadores de pilha e modificação de instruções. Para tarefas simples (logging, permission check), AspectJ é mais eficiente. Para transformações complexas (instrumentar cada chamada na aplicação), ASM dá controlo total sobre o bytecode.

AOP no iOS: Objective-C Runtime e abordagens Swift

AOP no iOS historicamente tem sido implementado através do Objective-C Runtime — method swizzling e message forwarding. A biblioteca Aspects (2014) fornece uma API simples: [UIViewController aspect_hookSelector:@selector(viewDidLoad) withOptions:AspectPositionAfter usingBlock:...]. No entanto, Aspects e bibliotecas semelhantes têm limitações: não funcionam com classes pure Swift e podem entrar em conflito umas com as outras.

A abordagem moderna é InterposeKit (Swift, código aberto em 2023). A biblioteca usa Swift runtime e fishhook para intercepção segura de métodos sem Objective-C Runtime. InterposeKit suporta métodos Swift, @objc e funções C, tem uma API type-safe e previne dupla intercepção. Uma alternativa são os Combine Publishers (Swift), que substituem AOP no paradigma reativo.

SwiftUI elimina a necessidade de AOP: os modificadores .onAppear, .onReceive, .task adicionam comportamento transversal declarativamente. De acordo com a WWDC 2023, a Apple recomenda usar modificadores SwiftUI e Custom Attributes em vez de AOP para preocupações transversais em novos projetos. Em projetos UIKit, AOP através do Runtime continua justificado para monitorização (swizzling viewDidAppear) e logging centralizado.

AOP vs OOP: comparação e quando escolher

AOP não substitui OOP, mas complementa-o. OOP fornece modularidade da lógica de negócio através de classes e objetos. AOP modulariza preocupações transversais que OOP não consegue isolar sem duplicação. A aplicação ideal usa OOP para a arquitetura principal e AOP para tarefas de infraestrutura.

Quando escolher AOP: se notar boilerplate repetido em cada método (logger.info, securityCheck, transaction.begin/commit), se alterar um comportamento transversal exigir editar centenas de classes, ou se estiver a introduzir monitorização num projeto legado sem refatoração. Quando NÃO escolher: para aplicações CRUD simples onde a sobrecarga do weaving não é justificada; se a equipa não estiver familiarizada com o paradigma (um aspeto mal escrito é mais difícil de depurar do que código duplicado).

Impacto do AOP na arquitetura do projeto

AOP muda a abordagem arquitetónica: a funcionalidade transversal já não está dispersa pelas camadas, mas reunida em aspetos. Isto melhora a modularidade mas cria dependências implícitas — o desenvolvedor não consegue ver que um método está a ser interceptado por um advice sem ler o aspeto. Recomenda-se documentar as expressões pointcut e limitar estritamente os aspetos à camada de infraestrutura, evitando AOP na lógica de negócio.

De acordo com um estudo do Google Scholar (2024), projetos AOP têm 35% menos linhas de código duplicado em comparação com soluções puramente OOP. No entanto, o número de bugs por aspeto é 2 vezes maior do que por classe devido à execução implícita do advice. Recomenda-se usar AOP apenas para tarefas de infraestrutura e cobrir os aspetos exaustivamente com testes.