Introduo a programao orientada a aspectos A programao Orientada a Objetos (Object-Oriented Programming OOP) utilizada para dar mais modularidade

e ao cdigo desenvolvido e para deixar o software mais parecido com o mundo real. Ao utilizar corretamente objetos, podemos mapear quase que diretamente os problemas do mundo real para software. Por exemplo, ao modelarmos um sistema que cuida da aprovao de emprstimos, podemos trazer os conceitos envolvidos (emprstimo, crdito, cliente...) diretamente para nosso software, como no diagrama Abaixo:

Entretanto, ainda existem e existiro por muito tempo limitaes tcnicas que fazem com que os conceitos de negcio que modelamos sofram invaso de conceitos tcnicos, como autenticao de usurios, transaes com bancos de dados e arquivos de log. Estes conceitos no fazem parte do domnio do problema, existem apenas para satisfazer a necessidade do software. Normalmente, o que se faz com OOP simplesmente misturar estes conceitos, criando cdigo que mistura regras de negcio com limitaes tecnolgicas. Por exemplo, o mtodo abaixo traz o cdigo de negcios necessrio para aprovar um emprstimo no exemplo acima.

public void aprovar() throws MaximoPrestacoesExcedidoException, CreditoExcedidoException{ //Checa se o emprstimo excede o limite do cliente if(!cliente.podeEmprestar(this.valor)){ this.status=Status.NEGADO; throw new CreditoExcedidoException("Emprestimo muito alto"); } //Checa se o numero de prestaes maior que o limite if(prestacoes.size()>Prestacao.MAXIMO_PRESTACOES){ this.status=Status.NEGADO; throw new MaximoPrestacoesExcedidoException("O emprstimo deve ser pago em at "+Prestacao.MAXIMO_PRESTACOES+" vezes!"); } //se passou nas checagens: //emprstimo est aprovado this.status=Status.APROVADO; } Para que este cdigo tire proveito dos recursos de aplicaes modernas, por exemplo, para que possa participar de transaes no banco de dados e criar registros em um arquivo de log, ele precisa ser modificado para incluir cdigo que lida exclusivamente com isso, como abaixo. public void aprovar() throws MaximoPrestacoesExcedidoException, CreditoExcedidoException, SQLException, NamingException { Connection conexao = criaTransacao(); // Checa se o emprstimo excede o limite do cliente if (!cliente.podeEmprestar(this.valor)) { logger.log(Level.INFO, "Emprstimo [" + this.getCodigo() + "] negado por exceder crdito em [" + this.getValor().subtrair(cliente.getCredito()) + "]"); this.status = Status.NEGADO; throw new CreditoExcedidoException("Emprestimo muito alto"); }

// Checa se o numero de prestaes maior que o limite if (prestacoes.size() > Prestacao.MAXIMO_PRESTACOES) { logger.log(Level.INFO, "Emprstimo [" + this.getCodigo() + "] negado por exceder nmero mximo de prestaes [" + this.getPrestacoes().size() + "]"); this.status = Status.NEGADO; throw new MaximoPrestacoesExcedidoException( "O emprstimo deve ser pago em at " + Prestacao.MAXIMO_PRESTACOES + " vezes!"); } // se passou nas checagens: logger.log(Level.INFO, "Emprstimo [" + this.getCodigo() + "] aprovado"); // emprstimo est aprovado this.status = Status.APROVADO; conexao.commit(); } A parte destacada em amarelo o cdigo adicionado exclusivamente para que o trecho de cdigo tenha acesso aos recursos tecnolgicos. Como visto o cdigo de negcios, que o que realmente importa ao criar um software, fica soterrado no meio do cdigo de infra-estrutura, que existe apenas para satisfazer necessidades tcnicas. Mesmo neste exemplo extremamente simples o cdigo de infraestrutura j representa boa parte do cdigo da aplicao. Este problema faz com que mudanas em regras de negcio toquem o cdigo de infraestrutura, e vice-versa. No to fcil separar mudanas no aspecto no-funcional das funcionais, tudo est no mesmo lugar! Coeso a mtrica de quanto as linhas de cdigo em um mtodo (ou os mtodos em uma classe) so relacionados entre si. Um mtodo que faz conexo com banco de dados e processa regras de negcio tem baixa coeso. Tambm existe o problema da repetio de cdigo. Mesmo lidando apenas com cdigo de negcios podemos acabar tendo que repetir uma mesma rotina vrias vezes, linha por linha. No exemplo abaixo, vemos que ao ser criado um novo Emprstimo um Funcionrio precisa ser notificado do fato.

public Emprestimo solicitarEmprestimo() { Emprestimo novo = new Emprestimo(this); notificadorFuncionarios.notificar(novo); return novo; } Acontece que por uma mudana nos requisitos agora o funcionrio deve ser avisado em qualquer alterao no Status do Emprstimo, ento ao invs de fazer simplesmente this.status= o cdigo deve invocar este mtodo: private void setStatus(Status novoStatus) { this.status = novoStatus; notificadorFuncionarios.notificar(novoStatus); } Os dois mtodos, em classes diferentes, possuem rotinas para notificar o Funcionrio. No se trata apenas de encapsular esta rotina num mtodo, isso j foi feito (como o mtodo notificar()). O fato de este mtodo ser invocado sempre e da mesma maneira por diversas classes que pode se tornar um problema quando a implementao mudar. O ideal seria conseguir avisar ao sistema de que toda vez que os mtodos solicitarEmprestimo() e setStatus() (e qualquer outro que precise desta funcionalidade ) forem chamados deve ser disparada uma notificao. Conceitos Ortogonais e Aspectos Como visto, temos uma mistura de cdigo que lida com vrios interesses distintos ao escrever cdigo. Estes interesses so chamados de conceitos ortogonais. Conceitos Ortogonais (Orthogonal Concerns) so os diversos conceitos com que um cdigo de aplicao tem que lidar, como regras de negcio, segurana e conexes com bancos de dados. A idia por trs de Aspect-Oriented Programming tratar estes conceitos em lugares separados (entenda se classes separadas se estamos falando de Java) enquanto estamos desenvolvendo e uni-las em tempo de execuo. Estes conceitos que se integram ao cdigo de negcios so chamados de Aspectos.

Aspectos so a separao do trecho de cdigo que implementa conceitos ortogonais em classes distintas que so unidas em tempo de execuo (runtime). Ao invs de um grande bloco de cdigo que cuida de transaes, segurana, conexo com o banco de dados e ainda das regras de negcio ns podemos definir cada um destes aspectos em uma ou mais classes diferentes e a ferramenta de AOP ir fazer esta mistura enquanto o programa executado. O diagrama abaixo ilustra os diversos aspectos separados enquanto estamos desenvolvendo (esquerda) e o produto final em tempo de execuo, a classe que mistura todos estes aspectos (direita).

Claro que desta forma podemos tambm reaproveitar os aspectos em diversas classes. Geralmente voc vai precisar iniciar ou terminar transaes, verificar se o usurio tem os privilgios necessrios e demais aspectos em diversas classes de negcio, utilizando AOP voc pode criar aspectos apenas uma vez e lig-los a diversas classes de negcio. Aspectos so formados por: Advices - Cdigo a ser executado para cumprir uma tarefa (abrir ou fechar uma conexo, por exemplo) Pointcuts Lugares na classe-alvo (a classe com regras de negcio) onde o Advice deve ser invocado (por exemplo, sempre que um mtodo da classe UsuarioDao for chamado) Ou seja, podemos ter um aspecto descrito como: Toda vez que se invocar um mtodo cujo nome comece com fechar (por exemplo fecharVenda) execute o cdigo que inicia uma transao no banco de dados.

Usos Indicados AOP uma tcnica utilizada principalmente para duas coisas: prevenir repetio de cdigo e remover cdigo de infra-estrutura do cdigo da aplicao. Ao contrrio do mito popular, no existe uma competio entre AOP e OOP, uma complementa a outra. Tambm no h necessidade de utilizar OOP com tcnicas de AOP, teoricamente podemos ter os mesmos benefcios em outros paradigmas. Containeres como o Spring e EJB 3.0 utilizam AOP para atuar de forma transparente. Alm de interceptarem o fluxo de execuo do cdigo para controlar a forma com que as classes se comportam, eles oferecem recursos para que o programador defina seus prprios aspectos. importante notar que AOP uma tcnica til para fazer o que foi pensada: separar conceitos misturados em um nico artefato de cdigo (como uma classe) em outros, reutilizveis. A tecnologia em si poderosa e possibilita usos muito mais amplos, mas normalmente isso no uma boa idia, causando complexidade excessiva que no se faz necessria.