Todo paper ou palestra sobre programação orientada a aspectos sempre usam exemplos fracos, sejam eles logging, caching ou segurança. Ao ponto que o bom julgamento diz que é melhor não usar, ou então usar um framework castrado tal como o Spring-AOP. Alguns pesquisadores em Bruxelas criaram pointcuts temporais, que podem julgar o historio de execução de um programa para determinar quando e onde devem ocorrer. Em A Temporal Logic Language for Context Awareness in Pointcuts, Charlotte Herzeel, Kris Gybels e Pascal Costanza definem um modelo de pointcuts capaz de analisar contexto e histórico de um programa.
O conceito é muito interessante, assim como as aplicações que são mostradas. Eles usam uma loja eletrônica como base do estudo e o primeiro exemplo é bem interessante, dá desconto de 10% durante o checkout, caso estejamos em temporada de promoções. O pointcut acontece durante o checkout do cliente e somente se o predicado de temporada de desconto retornar verdadeiro para o dia corrente.
Porém é outro exemplo, ainda mais interessante, que mostra realmente as possibilidades do que o framework pode fazer. O pointcut é definido, em uma tradução livre do artigo, como “Dá um desconto de 10% no ítem que está sendo comprado, caso as promoções para esse tipo de ítem estavam ativas quando o usuário entrou (por exemplo, a loja faz promoções para artigos com excesso de estoque)”.
Esse tipo de pointcut não é possível de ser definido usando os recursos do AspectJ, pois ele opera sem conhecimento do contexto da aplicação e não consegue casar resultados que ocorreram no passado. Acredito, porém, que a dificuldade de implementar esses recursos no AspectJ, ou seja em Java, é a mesma que foi implementar em Lisp, a linguagem utilizada pelos pesquisadores.
Finalmente achei um bom exemplo de AOP que não é simplesmente um substituto para falta de boa metaprogramação e funções de primeira-classe, defeitos da linguagem Java, e, por conta disso, vou fechar esse artigo com a descrição do Kenny Tilton sobre um momento da ILC 2003:
I am reminded of Gregor Kiczales at ILC 2003 [the International Lisp
Conference] displaying some AspectJ to a silent crowd, pausing, then
plaintively adding, “When I show that to Java programmers they stand
up and cheer. ”
5 responses so far ↓
1 Vitor Fernando Pamplona // Apr 9, 2007 at 12:07 pm
AOP em regra de negócio? :S
Mas que macarronada hein? :)
2 Marcos Silva Pereira // Apr 9, 2007 at 12:26 pm
Eu sempre pensei na possibilidade de se usar AOP para alterar o comportamento do sistema, mas não dessa maneira, mas para customizações bastante especificas para um cliente ou outro. Só que eu geralmente achava a abordagem bastante estranha e usava uma interface para definir o serviço ao invés de usar AOP. Mas em alguns casos parecia razoável.
De qualquer maneira, não posso deixar de lhe fazer uma pergunta: essa abordagem parece transferir para o aspecto uma regra de negócio. Não é um complicador desnecessário? Por que não tratar esse comportamento temporal dentro da classe/metodo aspectada?
valeuz…
3 Rafael Fiume // Apr 9, 2007 at 4:08 pm
Beleza?
Interessantes mesmo os exemplos!
>Esse tipo de pointcut não é possível de ser
>definido usando os recursos do AspectJ…
Talvez isso seja possível utilzando os métodos ou classes listeners de callback dos session e message-driven beans no EJB 3.0 – que não deixam de ser um tipo de AOP, embora rudimentar.
Tanto um como outro conseguem ter acesso ao contexto no qual o serviço foi invocado através de InvocationContext.
Aliás, se não me engano, é por causa desse conhecimento sobre o contexto que Interceptors do EJB 3.0 não podem ser considerados realmente AOP, mas AOP-like.
4 kumpera // Apr 10, 2007 at 10:45 am
@Vitor.
Não vejo problema em definir regras de negócio usando AOP. Usando AspectJ ou SpringAOP fica ruim, porque são DSLs péssimas para desenvolver um sistema. Agora se você olhar o código Lisp do artigo vai notar como fica claro. Estão usando AOP de maneira semelhante a uma rules engine, não apenas para infra-estrutura, como se faz com os frameworks aleijados em Java.
@Marcos.
Os aspectos apresentados no artigo tratam realmente de cross-cutting concerns. Quando se fala no aspecto logging, suas várias instancias são independentes. Porém no caso do artigo, para se implementar a regra seria necessário alterar muitos pontos distintos do sistema, ou seja, teriamos uma regra realmente espalhada por todos cantos do sistema – o tipo de problema que AOP se propoe a resolver.
@Rafael.
Sim, é perfeitamente possivel implementar a mesma coisa usando AspectJ e interceptando os métodos em questão, porém toda parte de referencia temporal e contexto precisariam ser feitas manualmente, pois o framework não suporta isso.
5 Rafael Fiume // Apr 12, 2007 at 9:11 am
Kumpera, eu não me referi ao AspectJ, mas sim dos interceptadores da especificação EJB 3.0 – uso de @Interceptor, @Interceptors e @ArroundInvoke. O contexto você obtém a partir de InvocationContext.
Mas, sinceramente, é só um chute, pois ainda não tive tempo de ver os exemplo que você menciona aqui. Mas está me parecendo possível.
Leave a Comment