A programação orientada a aspectos , ou AOP (em inglês, programação orientada à aparência , ou AOP ) é um paradigma de programação que permite de forma independente as questões transversais (em inglês, preocupações transversais ), muitas vezes dentro da arte, questões de negócios , que formam o coração de um aplicativo. Um exemplo clássico de uso é a perfilagem , mas alguns princípios de arquitetura ou padrões de design podem ser implementados usando este paradigma de programação, como inversão de controle .
A programação orientada a aspectos é de fato uma técnica transversal (paradigma) e não está ligada a uma linguagem de programação particular, mas pode ser implementada com uma linguagem orientada a objetos como Python , bem como com uma linguagem procedural como C , sendo o único pré-requisito a existência de um tecelão de aspectos para o idioma alvo (cf. § Teceladores de aspectos ).
Os conceitos de programação orientada a aspectos foram formulados por Gregor Kiczales e sua equipe, então trabalhando para o Xerox PARC .
O paradigma foi patenteado por eles próprios nos Estados Unidos em 1999 .
As técnicas atuais de design e programação de software levam à divisão do software em módulos de software que, a priori, são independentes uns dos outros porque gerenciam diferentes aspectos do sistema projetado. Alguns desses módulos implementam tarefas de negócios ou mais tarefas de aplicativos, como autenticação de usuário, ou até mesmo serviços técnicos, como geração de rastreio ou multithread. Esses módulos, então, representam, no mesmo nível de abstração, diferentes considerações (diferentes aspectos) de um aplicativo, na maioria das vezes da camada de negócios.
Lista não exaustiva de módulos de exemplo:
Na prática, as considerações técnicas que os módulos devem implementar não apenas se sobrepõem (por exemplo, o gerenciamento de usuários também exige a geração de rastreio), mas também são distribuídas na camada de negócios: isso é emaranhamento ou interseção de aspectos técnicos. Assim, uma camada de software, inicialmente dedicada a gerenciar a lógica de negócios do aplicativo (por exemplo, um sistema bancário), ficará dependente de módulos que gerenciam os aspectos transacionais, registro, etc. ; o crescimento dessas dependências levando a um código mais complexo, seu desenvolvimento e sua manutenção.
A programação por aspecto permitirá extrair as dependências entre os módulos no que diz respeito aos aspectos técnicos que se cruzam e gerenciá-los de fora desses módulos, especificando-os em componentes do sistema a serem desenvolvidos denominados “aspectos”; eles são desenvolvidos para outro nível de abstração.
Assim, em vez de haver uma chamada direta para um módulo técnico a partir de um módulo de negócios, ou entre dois módulos técnicos diferentes, na programação por aspecto, o código do módulo em desenvolvimento concentra-se no objetivo perseguido (lógica bancária, para usar nosso exemplo ), enquanto um aspecto é especificado de forma autônoma, implementando um determinado aspecto técnico, por exemplo, persistência ou mesmo geração de traços. Um conjunto de pontos de inserção é então definido para estabelecer a ligação entre o aspecto e o código de negócio ou outro aspecto. Essas definições de ponto de inserção são definidas como parte do POA. Dependendo das estruturas ou linguagens de aspecto, a fusão do código técnico com o código de negócios é então realizada na compilação ou no tempo de execução.
Claro, se cada aspecto criado fosse ele mesmo para definir explicitamente em que ponto de execução ele deveria se encaixar no código de negócios ou em outro aspecto, ou seja, por exemplo, com uma dependência direta do módulo de negócios onde o código técnico deve ser inserido , o método apenas teria mudado o problema. Além disso, o truque usado por várias linguagens é usar um sistema de expressões regulares para especificar em quais pontos de execução do sistema o aspecto especificado deve ser ativado.
O software de negócios que descreve um ambiente distribuído é escrito de maneira convencional usando uma decomposição funcional ou de objeto. Quando o sistema é implantado, percebemos que as máquinas físicas nas quais o sistema será executado, na verdade, possuem características heterogêneas (potência, largura de banda, etc.) que impactam ou modificam as funcionalidades do software original.
Uma abordagem comum neste caso seria aplicar patches em todo o código para adaptar o software ao seu ambiente de execução real. Com as ferramentas POA é possível especificar facilmente as alterações necessárias sem tocar nas fontes do código original, cuja lógica permanece intacta.
As ferramentas de programação baseadas em aspectos são, de fato, semelhantes aos modificadores ( before, aftere around) encontrados em linguagens como LISP , às quais foi adicionada a possibilidade de descrição de inserção declarativa.
Um aspecto, portanto, torna possível especificar:
O acoplamento entre os módulos gerenciando aspectos técnicos pode ser reduzido de forma muito significativa, usando este princípio, que tem muitas vantagens:
A tecelagem de aspectos que em última análise é apenas a geração automática de código inserido em determinados pontos de execução do sistema desenvolvido, produz um código que pode ser difícil de analisar (porque é gerado automaticamente) durante as fases de desenvolvimento. Software (depuração, teste ) Mas, na verdade, essa dificuldade é da mesma ordem que aquela trazida por qualquer decomposição não linear (funcional ou objeto, por exemplo).
No entanto, uma implementação como AJDT (acrônimo para AspectJ Development Tools ), baseada no AspectJ , oferece ferramentas sofisticadas que permitem que você alterne perfeitamente, no modo de depuração, do código de uma classe para o de um aspecto.
A programação orientada a aspectos, por oferecer um paradigma de programação e novos conceitos, desenvolveu um jargão muito específico que não facilita a compreensão de seus conceitos, que são, em última análise, simples mas poderosos.
Aspecto um módulo que define plugins e seus pontos de ativação; Plugin ( conselho ) um programa que será ativado em um determinado ponto de execução do sistema, especificado por um ponto de junção; Tecelagem ou trama inserção estática ou dinâmica no sistema de software da chamada a plug-ins; Ponto de corte, ação, corte ou enxerto ( pointcut ) localização do software onde um enxerto é inserido pelo tecelão de aspecto; Junção ou ponto de execução local específico no fluxo de execução do sistema, onde é válido inserir um plugin. Para esclarecer, não é possível, por exemplo, inserir um plugin no meio do código de uma função. Por outro lado, podemos fazer isso antes, ao redor, ao invés de ou depois da chamada da função. Considerações transversais ou questões transversais mistura, dentro do mesmo programa, de subprogramas distintos que cobrem aspectos técnicos distintos.Existem duas estratégias principais para tecer aspectos: