AOP e Interceptors, Filters e afins

O lance de usar AOP é por que criar comportamentos horizontais para um sistema com o paradigma OOP é várias vezes mais complexo do que se escrever com um aspecto.

A AOP veio para cubrir algumas dificuldades encontradas na OOP

Podemos definir que os objetivos dos frameworks citados acima são semelhantes. No entanto, AOP não poderia ser considerada como um framework e sim como uma forma de programar, um novo paradigma de programação, assim como a OO. A POA, trabalha em paralelo com a OO e pode ser utilizada para possibilitar um nível maior de abstração, ou seja suas camadas do software serão bem distintas.

Por exemplo, podemos ter uma camada que trara dos interesses do sistema utilizando uma camada de persistencia, distribuição e filtros. A POA ficaria como uma camada para atender os requisitos não-funcionais, por exemplo, a implementação de um Log ou até mesmo em questões de segurança.

Supondo que seja necessário a implementação de um Log em uma classe de Pedidos, por exemplo, com a OO é necessário fazer a manutenção e verificar dentro do contexto da aplicação sempre que ocorra uma instancia desta classe, ou seja terá diversos pontos em comum. Com a POA, pode-se fazer mecanismos que quando ocorreram alguma instancia dessa classe, seja em qualquer lugar, é tratado o Aspecto. Bom, pode-se que um Filter, Interceptor, etc… resolva isso também, mas deve ocorrer manutenção na aplicação. Com AOP pode-se fazer isso transparente, em um servidor de aplicação, por exemplo.

Bom, isso é um assunto bem interessante e acho que vai ter muitas respostas… existe um livro bem legal que fala sobre isso da Editora Novatec que é AspectJ - Programação orientada a aspectos com Java.

Muito interessante !!!

T+

Também acho, mas ninguém respondeu o meu último tópico sobre isso: http://www.guj.com.br/posts/list/220339.java

javando:

Oi gente, faz tempo que eu nao pergunto nada hein rs

Eu tava dando uma olhada em AOP, fazia um tempo que eu não mexia e comecei a me questionar sobre em que momento usar aspectos.
Sei que não é a mesma coisa, mas interceptadores em EJBs fazem a trabalho adicionar tarefas antes, depois e ao redor ed um método ou de uma transação por exemplo.
Se não tiver usando um servidor de aplicação, pode-se usar os recursos do Spring do Seam que trazem opções de execução antes ou depois de um bean e tals
No caso de banco de dados, tem os listeners do hibernate (caso esteja usando) que também faz esse tipo de coisa, adicionar funções de foma modular em metodos existentes.

Agora, visto essas “opções acima”, como identificar se devemos usar AOP ou outro tipo de interceptação de outro framework?

espero q eu tenh oconseguido explicar minha dúvida :S

brigadão gente

Na minha opinião existem dois casos:

1- Quando você não tem opções, por exemplo, você está usando hibernate, mas não está EJB. Você vai usar Interceptor ou Listener do hibernate? Ou seja, você não vai colocar EJB em um projeto que já está funcionando apenas para usar Interceptor. Você resolve de outra forma.

2- Quando você tem opções, por exemplo, você tem hibernate e EJB no projeto. Nestes casos eu prefiro colocar o mais próximo das regras de negócio. Acho que é a melhor camada para colocar esses “serviços”.

Há, só para concluir…

No teu caso, já que tem os frameworks, recomendaria a utilização dos interceptors e filters pelo simples fato dessas tecnologias já estarem presente em nosso ambiente. Tivemos uma situação assim, para um sistema de segurança, e acabamos fazendo com filter (phase listener - jsf ) mesmo, fizemos todos os testes e ficou melhor (mais simples) com filter.

Então AOP continua sendo uma segunda opção…

Mais ou menos…

Você prefere usar o Hibernate ou escrever seu próprio framework ??? AOP é primeira opção para quem escreve frameworks, já para nós ele entra como segunda opção, sim.

Mais ou menos…

Você prefere usar o Hibernate ou escrever seu próprio framework ??? AOP é primeira opção para quem escreve frameworks, já para nós ele entra como segunda opção, sim.

Hum … gostei da definição …