Dando sequência aos meus estudos sobre Micronaut, dei de cara com mais um conceito que não conhecia muito e resolvi pesquisar mais sobre.

Dessa vez, me refiro à Programação Orientada a Aspectos que, para a surpresa de ninguém, o Spring também trabalha com ela (se você quiser).

A Programação Orientada a Aspectos (ou Aspects Oriented Programming - AOP) foi um estudo desenvolvido por: Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes,Jean-Marc Loingtier, John Irwin em 1997.

Esse estudo teve por objetivo melhorar alguns pontos complexos no desenvolvimento de código que nem o paradigma procedural e nem a orientação a objetos conseguiam resolver. Os autores apontam que exatamente esses pontos complexos são os aspectos do design de código que, novamente, a OOP não consegue resolver por mais que ela busque representar o mundo real.

Por conta disso, os autores apresentam uma nova técnica de programação chamada orientada a aspectos, onde é possível usar isolamento de forma apropriada, reutilizar código e composição tudo baseado no aspecto do código. O que eu acredito ser bem relevante sobre o artigo dessa galera é que, em momento algum, eles não falam que OOP, Programação Procedural ou até mesmo a Programação Funcional são ruins, mas sim que a AOP é uma forma de complementar essas programações em pontos que geralmente deixam o desenvolvimento com um código complexo de ser desenvolvido e, posteriormente, dar manutenção.

Ok, mas o que exatamente é um aspecto na programação?

Enquanto um componente tende a ser uma unidade do sistema como, por exemplo, uma imagem, conta bancária, etc. Aspectos são propriedades que afetam a performance e a semântica dos componentes de forma sistemática, por exemplo, padrão de acesso e sincronização de objetos concorrentes, conforme imagem abaixo:

Fonte: Aspect-Oriented Programming traduzido por: Carolina Fonseca

Para facilitar mais na explicação, os autores usam erros e falhas como base, pois sabemos que são os pontos mais comuns no dia a dia como desenvolvedores, afinal, sempre teremos que customizar/adicionar algum handle quer seja para captar qualquer tipo de erro que dê na aplicação ou lidar com erros/falhas específicas.

"Many performance-related issues are aspects, because performance optimizations often exploit information about the execution context that spans components."

Muitos problemas relacionados a performance, são aspectos. Porque a otimização de performance sempre explora a informação sobre o contexto de execução onde os componentes estão.

Mão no código

Vamos ver um exemplo prático usando Java como base, no caso, vamos utilizar a Biblioteca Digital sugerida na imagem anterior:

public class Livro {
    String título, autor;
    int isbn;  

    public String getTitulo(){
        return título;  
    }
    public String getAutor(){
        return autor;  
    }
    public int getIsbn() {
        return isbn;  
    }
}

public class Repository {
    private Livro livros[];
    private int nlivros = 0;

    public Repository (int dbsize)  {    
        livros = new Livro[dbsize];  
    }

    public void registrar (Livro liv)  {    
        livros [nlivros++] = liv;  
    }

    public void retirar (Livro liv)  {    
            ... 
    }

}   

Os autores destacam que programas como o acima, onde precisam gerenciar todas as instâncias criadas de suas classes e as chamadas de métodos, não são capazes de fazer esse gerenciamento todo sozinho, afinal, estamos falando de uma estrutura cujo foco é a abstração que queremos fazer do sistema real e não como ele vai gerenciar todas as sua chamadas.

O mais indicado seria o uso de reflection para acessar essa comunicação de forma distribuída, porém, criar reflection no nível de detalhe que a OOP precisa, acaba se tornando algo muito complexo.

É aqui onde temos uma oportunidade real de se utilizar a AOP:

remote Repository { 
        void registrar (Livro); 
        void retirar (Livro: copy isbn); 
        Livro: copy isbn busca(String);}

Acima temos um trecho de código com foco no aspecto da comunicação. Basicamente, ele comunica ao Repository que quando novos livros são registrados, ele deve criar uma cópia daquele objeto e quando o livro é retirado ele deve copiar somente o número de isbn, o restante do livro não é copiado a menos que seja preciso mais tarde.

O Join e as reflections

Em AOP, temos um conceito chamado Join que nada mais é do que o momento em que unimos o nosso componente ao seu aspecto, uma vez que, em inglês, join significar unir, esse conceito faz total sentido.

E ela faz mais sentido ainda quando falamos de reflection e metaobjetos, porque um sistema reflexivo disponibiliza a base da semântica e implementação da linguagem que estamos utilizando. Falando da metalinguagem, temos acesso à todas as chamadas de funções e stack de execução que, a nível humano, nunca conseguimos ver. Vendo por esse ângulo, é no baixo nível onde é possível aplicarmos os joins da AOP de forma que a reflection faça todo o restante do trabalho, dessa forma, temos os nossos aspectos criados para fins de controle das instâncias e vinculados ao reflection que nem precisamos criar já que utilizamos da própria linguagem para tal.

Conclusão

Admito que enquanto lia o artigo que "criou" o AOP, não esperava encontrar o uso de reflections nele, mas passou a se fazer muito sentido de quando comparamos o uso delas no Spring e no Micronaut.

O Spring já faz as reflections todas de uma vez, ou seja, já vamos fazendo o mapeamento de aspectos no tempo de compilação, ao passo que o Micronaut também faz esse gerenciamento de aspectos, porém somente do que realmente está sendo utilizado na aplicação mas em tempo de pré-compilação, mas falarei mais sobre isso nos próximos artigos ;)

Espero que tenha gostado e se acha que faltou algo ou escrevi algo sem sentido, me chama para conversamos!

Fonte: https://www.cs.ubc.ca/~gregor/papers/kiczales-ECOOP1997-AOP.pdf