É só alguém citar que via utilizar tal componente, seja este para logar, exception handling, controle transacional, que já aparece um gritando que “não, de jeito nenhum, isso polui o código, tras mais problema do que solução, tira performance, para fazer debug é um inferno, se descompilar polui o código, tira a index dos erros”. Note que todas as desculpas são pela provavel falta de experiencia com aspectos dinamicos (apenas em runtime).
Há uma tendência natural das pessas de:
a) Temer o desconhecido;
b) Falar mal do que não utilizando;
c) Acreditar nos comentários dos concorrentes, principalmente se você usa o concorrente.
d) Exagerar informações parciais, ou aumentar experiências negativas, mesmo que elas tenham sido incompletas.
No fórum vemos vários exemplos de todos esses casos, todos os dias. Poucos são os que travam uma discussão querendo realmente argumentar e contra-argumentar, para depois formar uma opinião coesa sobre determinado assunto.
é, ja vi muito disso por ai.
Tenho um livro em casa que trata de aspectJ, li só até a metade pro falta de tempo, pra mim é um mundo novo de novas possibilidades que não pode ser deixado de lado.
Aproveitando o tópico…
De uma forma simplificada, poderiam me explicar como funciona a Orientação a Aspectos?
[]'s
Parece que vc mesmo ja respondeu a pergunta. 
Até agora não passei por nenhuma situação onde eu não pudesse usar um simples proxy - estático ou dinâmico - no lugar de um aspecto.
sou da turma dos ceticos em relacao a AOP, ainda mais qdo o pessoal vende como a super solução.
os exemplos classicos de AOP sao log/auditoria, exceptions, transacao e autenticacao/autorizacao.
o que pergunto é:
-
realmente dá pra escrever um log generico executando antes/depois/em volta do metodo?
ou log tem q ter msgs bacanas e explicativas que vao ajudar a entender depois o problema? -
realmente dá pra tratar todas as exceptions de um jeito só? ou elas estao la justo para q sejam tratadas adequadamente…
se for pra tratar de forma generica só pra nao vazar pg de erro pro usuario, melhor usar <error-page> -
precisa de AOP pra autenticacao? ou um Filter/Interceptor resolve?
-
precisa de AOP pra transacao? quem ainda fica escrevendo commit espalhado pra la e pra cá?
ja nao usamos frameworks que fazem isso? (ejb, spring)
ou colocamos um Interceptorzinho q resolve?
eu nao tenho nada contra AOP. só nao conseguiram me mostrar ainda um lugar onde AOP realmente fosse mais util que uns patternezinhos aqui e ali
[quote=MrDataFlex]É só alguém citar que via utilizar tal componente, seja este para logar, exception handling, controle transacional, que já aparece um gritando que “não, de jeito nenhum, isso polui o código, tras mais problema do que solução, tira performance, para fazer debug é um inferno, se descompilar polui o código, tira a index dos erros”. Note que todas as desculpas são pela provavel falta de experiencia com aspectos dinamicos (apenas em runtime).
[/quote]
Por uma razão muito simples : AOP é um hype.
Se vc segue OOP como mandam as regras vc não precisa de AOP. AOP é apenas a criação de proxies dinamicos.
Vc pode fazer a mesma coisa de forma mais simples com a classe Proxy do java padrão.
Se vc define seus tipos como interfaces então é muito simples colocar um proxy. Para web vc usa um filtro da servlet API que vai
intercepta as chamadas e respostas.
Como o Sérgio Lopes já falou, no fim das contas vc precisa de um nivel de granularidade mais fino e essas coisas de log e exception handling não são realmente cross concerns. Transações podem até ser, mas colocar toda uma estrutura para só fazer isso é despedicio. um proxy bem aplicado junto a um factory ou um injetor automático e pronto.
Na era dos injetores automáticos de dependencia AOP é inutil. Só serve para atrapalhar. Aprenda IoC e a usar um injetor automático que ganha mais.
eu acho que log com AOP é mais log de trace/debug… Não substitui o log “manual”
Eu também acho que não é uma boa idéia AOP pra tratamento de exceptions.
Interceptors resolvem, mas eles estão muito atrelados a uma framework, AOP é bem mais genérico, esta atrelado a execução de metodos.
Por exemplo, o teu interceptor de segurança não funcionaria muito bem pra fazer segurança de chamadas SOAP, EJB, etc…
No livro Spring in Action o autor disse que Interceptor é uma forma primitiva de AOP. Eu não concordo com ele, mas entendo por que ele pensa assim.
AOP é uma das formas de você fornecer ortogonalmente serviços como autorização, transação, etc, mas não é a unica nem a mais recomendada. No fim, com Spring/EJB você acaba usando AOP e nem sabe