O artigo fundamenta o paradigma Orientado a Aspecto abordando seus elementos e duas formas de implementação Java. Uma através da linguagem AspectJ e outra através do framework Spring AOP. O artigo aborda também os benefícios do uso de design patterns através de AOP.
Para que serve:
Este artigo fundamenta e ilustra as implementações e conceitos do paradigma Orientado a Aspecto, utilizando duas ferramentas conhecidas: AspectJ e Spring AOP.
Em que situação o tema é útil:
O paradigma Orientado a Aspecto deve ser utilizado como um complemento ao paradigma Orientado a Objetos. Portanto, na análise e modelagem de uma aplicação, podemos usufruir destes conceitos para facilitar o desenvolvimento da aplicação.
Fundamentos de AOP para aplicações Java:
O uso do paradigma Orientado a Aspecto (AOP) complementa implementações no modelo orientado a objeto, facilitando o desenvolvimento das aplicações e separando a implementação de regras de negócio de infra-estrutura. AOP traz mecanismos que interagem e controlam objetos em tempo de execução e compilação, abstraindo qualquer implementação que afetará o uso da aplicação “horizontalmente”. O corte “horizontal” na aplicação é feito quando funcionalidades genéricas que interagem diversas vezes no ciclo de vida dos objetos são candidatas a esta abstração por parte de um aspecto.
AOP também facilita a utilização de design patterns dentro de uma aplicação, atuando em segundo plano sobre o controle dos objetos por parte da implementação destes padrões.
Como todos os paradigmas de programação, AOP (Aspect-Oriented Programming) é baseado em conceitos pré-existentes, que já foram explorados no passado, porém são limitados para algumas situações. AOP utiliza vários conceitos de diferentes domínios de tecnologia, focando-se em metaprogramação. Também se utiliza do conceito "programação baseada por contratos", considerado chave no paradigma orientado a objeto (OO), mas pouco utilizado. Este conceito é realizado através de pré-condições e pós-condições, implementáveis em AOP por instruções (métodos) "before" e "after".
Atualmente, o paradigma orientado a objeto vem sendo primordial para o desenvolvimento de aplicações. A cada momento, novas aplicações complexas são escritas utilizando linguagens orientadas a objeto, em nosso caso, Java. AOP aparece neste cenário não como uma alternativa, e sim, como um complemento ao paradigma orientado a objetos.
Duas limitações podem ser vistas ao desenvolver de aplicações orientadas a objetos: crosscutting functionalities e code scattering.
A primeira limitação refere-se ao desenvolvimento da integridade de negócio, onde serão criadas verificações sobre dependências no modelo de negócio, como por exemplo: Um objeto Cliente não pode ser removido enquanto uma Ordem de Pagamento, em seu nome, não for paga. A solução mais comum, conforme descrito acima é aplicar verificações (os famosos IFs) dentro do método de remoção do Cliente. Porém, tal comportamento não deve ser atribuído ao Cliente, e sim, ao controle de Ordem de Pagamento. Uma solução mais eficiente é adotar o uso de AOP para realizar o comportamento esperado à remoção do Cliente. Essa solução será realizada através de um aspecto. A Figura 1 mostra a integração de um AOP em um modelo de negócio.
Figura 1. Integrando funcionalidades de “crosscutting”.
Observem que o aspecto (no caso, implementado pelo Hibernate, que pode ser considerado uma ferramenta AOP especializada no aspecto de persistência) abstraiu das classes de negócio o uso da persistência, assim como a dependência de bibliotecas para tal objetivo. Quanto maior a transparência do uso de tecnologias das classes da aplicação, maior fidelidade e coerência ao modelo de negócio.
A segunda limitação refere-se à mudança dinâmica de métodos e seus argumentos. Esta limitação alerta para constantes atualizações ao código da aplicação, conforme sua evolução e manutenção. Ou seja, caso exista dependência na chamada de métodos de um serviço, que terá seus argumentos alterados, por exemplo, esta modificação terá um impacto grande em sua estrutura de objetos. Para diminuir este problema, devem-se agrupar os métodos deste serviço que realizam o processo ou processamento de negócio em um método, tendo assim, uma chamada e apenas uma dependência a este serviço, veja a Figura 2.
Figura 2. O impacto de um aspecto em uma estrutura com múltiplas dependências de um processo comum.
As dependências criadas entre objetos da aplicação e APIs técnicas ou bibliotecas de terceiros, causam uma limitação indireta no uso do paradigma orientado a objetos, tanto em implementação como em modelagem da aplicação.
Este problema é comum em aplicações Java orientada a objetos quando se utilizam de frameworks como: Hibernate, JSF (Java Server Faces), Struts, etc. O modelo de objetos não leva em consideração o encapsulamento para o uso de tais dependências, causando assim, um forte acoplamento da aplicação com as bibliotecas de terceiros.
O conceito de Dependency Inversion (inversão de dependência)
ajuda a aumentar o encapsulamento da aplicação e baixar a dependência entre os
objetos da aplicação e bibliotecas de terceiros, veja a ...
