Ir ao conteúdo

O que é Programação Orientada à Aspectos?

Notei uma procura bastante grande sobre  Aspect Oriented Programming (AOP), ou em português, Programação Orientada a Aspectos (POA). O que vem a ser programação orientada a aspectos? Se você me acompanha, já viu o artigo sobre programação Orientada a Objetos (POO), onde você aprendeu sobre os seus 4 pilares. Se não se recorda, acesse o link Introdução à Programação Orientada a Objetos (POO)

Vale ressaltar que o Paradigma de Programação Orientada a Objetos  é um dos métodos mais utilizado em desenvolvimento da atualidade pelo fato da POO possuir a capacidade de abstrair os objetos reais e abstratos em classes garantindo melhor visibilidade ao código. Porém, mesmo com seus recursos, a POO “não consegue” tratar alguns aspectos dos sistemas “corretamente”, como, por exemplo, o controle de acesso (logging). Como assim Walmir? Calma, vou explicar kkk  coloquei “não consegue” e “corretamente” entre aspas, porque a POO tem princípios que não podem ser violados. Tem duas palavrinhas que você vai se deparar muito no mundo da programação orientada a objetos: coesão e acoplamento. Um dos princípios chave da POO é buscar manter o máximo possível uma alta coesão e o baixo acoplamento em nossos projetos.

O que é alta coesão?

Coesão tem relação total com o princípio de responsabilidade única. Quando falamos em alta coesão, estamos falando que as responsabilidades de um determinado elemento, como exemplo uma classe,  estão fortemente relacionadas e altamente focadas na sua própria responsabilidade. O seu oposto, baixa coesão, gera excesso de responsabilidade sobre um mesmo objeto, difícil reaproveitamento de código, alta complexidade e ocasiona uma maior dificuldade na manutenção do código. 

O que é baixo acoplamento

Já o acoplamento tem relação direta com a ligação entre elementos. Ou seja, quando temos um baixo acoplamento,  temos menor dependência entre as classes, podemos mudar uma classe sem que outra que esteja de alguma forma relacionada interfira diretamente na sua funcionalidade, com isso, aumentamos muito o potencial de reutilização de código.

Futuramente vou fazer um artigo com mais detalhes sobre coesão e acoplamento com alguns exemplos bem elaborados.

Entendendo sobre coesão e acoplamento, já lhe garante entender boa parte do POA. A POA surgiu como uma técnica de programação complementar a POO, que visa o tratamento, de maneira independente do entrelaçamento entre as diversas classes em nosso sistema, promovendo a reutilização e facilitando a manutenção do software. Justamente tentar resolver  a alta coesão e baixo acoplamento, sacou?

Voltando a questão do “log”  que citei logo acima, vamos supor que você tem uma classe de serviço para salvar um cliente. Imagine que você quer que toda vez que método save do cliente seja acionado, você queira medir o desempenho do método em questão de tempo. Você faria algo mais ou menos assim: 

Programação Orientada a Aspectos
Esse é apenas um exemplo incompleto

Observe que esse código está “assassinando” a POO no princípio de coesão. Veja que esse método está com duas responsabilidades, salvar o cliente e registrar log do tempo do método. Com isso, fere o princípio de responsabilidade única. A esse tipo de comportamento, chamamo de interesse transversal (cross-cutting concerns).

Normalmente a POA pode ser utilizada para executar ações que não estão relacionadas à regra de negócio do seu sistema, como log, cache, etc. Essas ações podem ser colocadas em uma parte separada do seu sistema e depois reutilizadas. Normalmente existem duas maneiras de conseguir isso. Injetando código automaticamente por um pré-processador antes / depois de um método ou anexando classes de proxy que interceptam uma chamada de método e podem executar as coisas antes / depois de uma chamada de método.

Diagrama de Aspectos POA

Elementos básicos da Orientação a Aspectos

A orientação a aspectos possui alguns elementos básicos descritos a seguir, baseado na explicação destes conceitos por Chavez (2004) e Tirelo (2004):

  • Componente: unidade funcional expressa em uma linguagem de componentes; Propriedades de um sistema, no qual a implementação pode ser encapsulada de forma limpa em um procedimento generalizado.
  • aspecto (aspect): unidade não funcional expressa em uma linguagem de aspectos; propriedades de um sistema, no qual a implementação não pode ser encapsulada em um procedimento generalizado.
  • crosscuting: entrelaçamento entre os interesses de domínio e os interesses ortogonais ou transversais como já falamos.
  • pontos de junção (join points): são as partes do meu sistema que precisam de controle transacional.
  • conjuntos de junção (point cuts): elementos da semântica da linguagem de componentes com os quais os programas de aspectos coordenam; elementos compostos por pontos de junção que tem por objetivo reunir informações a respeito do contexto dos pontos selecionados. Ou seja, point cuts são expressões utilizadas para identificar os join points
  • Advices: São os métodos que serão executados nos join points em um determinado momento a ser escolhido para execução:
    • Before
    • After
    • After Returning
    • After Throwing e
    • Around
Funcionamento dos Aspctos POA
  • regras de junção: código relativo aos requisitos ortogonais que deve ser executado nos pontos de junção.
  • processo de combinação (weaving): composição entre os componentes e os aspectos.
  • combinador de aspectos (aspect weaver): processador de linguagem especial que oferece suporte à composição entre os componentes e os aspectos. 

Observe que até para entender sobre os elementos da POA, requer um pouco de esforço. Quando for pensar em POA, foque na aparência exterior das suas classes, por isso chama-se aspectos. A orientação a aspectos não é nem de perto um substituto a orientação a objetos e sim um complemento para diminuição do acoplamento dos módulos possibilitando mais facilidade de manutenção, maior reaproveitamento do código e maior organização do sistema.

Parece assunto novo não é? Mas a primeira implementação da Programação Orienta a Aspectos, o AspectJ para a linguagem Java, surgiu na década de 80. 

Existem dezenas de implementações de extensões de linguagens com foco em POA para outras linguagens, como GO! AOP do PHP, Aspect# do CSharp(C#), AspectJS do JavaScript e Aquarium do Ruby, etc.. Contudo, o AspectJ continua sendo, sem dúvida, a mais popular. Escolha uma dessas extensões que mais se adequa às suas necessidades e se aprofunde em sua implementação. É muito interessante e vai agregar bastante nos seus conhecimentos de arquitetura de software. Até o próximo artigo!

Confiança Sempre!!!

Fontes: 

Olá! Sou Walmir, engenheiro de software com MBA em Engenharia de Software e o cérebro por trás do GrowthCode e autor do livro "Além do Código". Se você acha que programação é apenas sobre escrever código, prepare-se para expandir seus horizontes. Aqui, nós vamos além do código e exploramos as interseções fascinantes entre tecnologia, negócios, artes e filosofia. Você está em busca de crescimento na carreira? Quer se destacar em um mercado competitivo? Almeja uma vida mais rica em conhecimento e realização? Então você chegou ao lugar certo. No GrowthCode, oferecemos insights profundos, estratégias comprovadas e um toque de sabedoria filosófica para catalisar seu crescimento pessoal e profissional.

Publicado emJavaProgramação

Seja o primeiro a comentar

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *