Quando a Programação Orientada a Aspectos surgiu ela prometia tornar nosso código muito mais modular, principalmente em relação aos ‘crosscutting concerns’. O que torna muito dificil de justificar seu uso é o fundamental problema de AOP desentruturar um sistema OO, já que a forma diferente pelo qual os aspectos são vinculados ao comportamento do sistema.
AOP tem com grande vantagem centralizar algumas partes do sistema, que somente com OO ficariam todas espalhadas. Logging dificilmente é um bom exemplo disso, já que não é possivel capturar a semântica do que aconteceu - tracing, em contrapartida, é um grande exemplo para uso de aspectos.
Existem várias publicações sérias que mostram falhas desse paradigma, destas eu destaco: AOP considered harmful (2004), Domain models are aspect free (2005) e AOP and the antinomy of the liar (2006). O primeiro é mais sensacionalista e fraco em argumentos, mas os outros dois são uma ótima leitura.
O fato que mais me desagrada é que na maioria das vezes estamos usando simplesmente os padrões Decorator ou Proxy auxiliados de alguma configuração, via annotations ou xml. Os poucos casos que vi fazerem mais que isso, o problema era que estavam usando uma linguagem sem nenhum mecanismo de meta-programação e logo tornaram este um “aspecto” do sistema.
Outro dia no trabalho fui questionado sobre a opção de usarmos AOP no meu atual projeto, fui radicalmente contra porque acho que compra mais problemas que solução. Eu preferiria utilizar uma linguagem com maior poder de expressão que AOP para amenizar este fato.
Update: O Diego, meu revisor de plantão, comentou sobre alguns problemas no artigo.
4 responses so far ↓
1 Diego Pires Plentz // Sep 24, 2006 at 3:40 pm
“Mas o fundamental problema de desentruturar um sistema OO sempre me pareceu dificilmente justificar seu uso.”
Eu li 3 vezes, e não entendi. Ou ficou meio confusa, ou eu que não entendo nada de AOP. Ou ambos. :)
2 Diego Pires Plentz // Sep 24, 2006 at 3:51 pm
Ah, faltou um
“Outro dia no trabalho fui questionado sobre a opção de usarmos AOP no meu atual projeto, fui radicalmente **contra** porque acho que compra mais problemas que solução.”
3 kumpera // Sep 24, 2006 at 4:02 pm
Diego, o problema que eu vejo como AOP interage com um sistema OOP é pela forma nada parecida como os pointcuts são definidos.
Pointcuts, no AspectJ por exemplo, são definidos usando aquela linguagem de query que é, de maneira tosca, um ‘SQL para código Java’.
Esee binding entre AOP e OOP que me faz achar que é um paradigma não muito salutar.
4 Fabrício Cozer Martins // Oct 28, 2006 at 10:14 am
Olá,
eu estudei AOP a um tempo atrás, e o que me motivou a estudar, desenvolver meu projeto final nessa tecnologia e empregá-la em um projeto comercial me fez sentir dias e dias de prazer, orgasmo profundo com uma forma divertida e modular de programar. Senti na pele o que a AOP pode beneficiar, por exemplo, depois que o sistema estava feito, e bem padronizado, foi levantado alguns requisitos pelo cliente, e uma das formas mais ágeis que tivémos foi utilizar pointcuts adicionando comportamento em determinados joinpoints que eram candidatos ao problema. Foi simples, fácil, entregamos pro cliente na metade do prazo que tínham definido, e possibilitou ainda maior controle na manutenção.
Não pode é ficar enchendo de código em AOP, mas tem coisas que se tornam muito mais fáceis quando se utiliza AOP.
Leave a Comment