"Como assim?" Eu ouço você pensando. "Algum dia ela esteve viva?" Pra mim, sim.
A programação orientada a aspectos (POA) surgiu oficialmente com esse nome em um artigo de 1997, mas é fruto de diversos trabalhos anteriores. A idéia da POA é simples e vem do conceito de metalinguagem. Qualquer chamada de método pode ser interceptada e substituida por outra. Por exemplo, você pode criar um cache simplesmente interceptando todas as chamadas ao seu modelo (no sentido MVC) e, antes de executá-las, verificar se o dado solicitado está no cache. Isso permite que você insira e retire funcionalidades no seu sistema sem alterar sua arquitetura.
Eu comecei a me interessar pela área em 1995, quando comecei meu doutorado. Acompanhei bem de perto e fiz minha dissertação nessa área. De volta ao Brasil, escolhi a POA como tema de uma disciplina de tópicos em engenharia de software, que lecionei três vezes na PUC. Ainda tenho a apostila que escrevi online se alguém se interessar, mas aviso que está desatualizada.
Depois disso, perdi o contato com a área e outro dia resolvi ver como estava progredindo. O que encontrei não foi muito animador. A POA ainda existe como área de pesquisa em universidades mas na prática não acontece muita coisa. A única conferência na área, a International Conference on Aspect-Oriented Developement, continua acontecendo mas parece haver pouco interesse. Na edição desse ano foram 19 artigos acadêmicos e 4 vindos da indústria, mas os autores são praticamente os mesmos que eu via na década passada, ou seja, a área atraiu pouca gente nova.
O pior, no entanto, é a evidência dada pelo Google Trends:
O interesse na busca "aspect-oriented programming" tem caído constantemente desde 2004, e olhe que em 2004 eu já sentia o interesse bem menor do que em 1999-2001, quando o tema estava mais em voga. Infelizmente a indústria nunca abraçou a POA, imagino eu que pela necessidade de um compilador específico. Eu mesmo já vi nos projetos de que participei várias oportunidades de se empregar a POA com sucesso, mas trocar o compilador do projeto inteiro para resolver alguns pequenos problemas? Acho que não.
Pelo menos a área deixa um legado. Hoje há técnicas como dependency injection que são derivadas diretamente dos conceitos introduzidos pela POA, chegando a frameworks modernos como o Guice. Mesmo assim, é triste ver algo no qual investi tanto tempo sumindo por falta de interesse. Até que a idéia era boa.
A lição que fica é: não se apaixone por novas tecnologias, pois é bem provável que elas desapareçam daqui a dez anos.
Mesmo o Guice abraçou algumas ideias de AOP; você consegue interceptar métodos, por exemplo. É bem menos poder do que se consegue com AspectJ, mas resolve uma boa gama de problemas, e sem trocar o compilador.
ResponderExcluirEu odeio o jeito que nós escrevemos testes. Nós resolvemos o problema errado com mocks. A solução pra testes é "eu não quero saber o que essa classe faz quando se chama foo(), então vou trocar essa classe no meu teste".
Pra mim a solução devia ser "eu não quero saber o que essa chamada específica do meu código faz, então vou interceptá-la e fazer *isso*". Com isso seria possível especificar, teste-a-teste, o 'caso' que se espera de cada chamada, sem fazer um roteiro do código sob teste.
Essa segunda solução seria linda com AOP. Talk is cheap.
Amigo, tecnologias novas são como animais de estimação. Passa pouco mais de uma década, eles se vão, deixam saudade. A melhor forma de manter os sentimentos "em forma" é adotar um filhote novo.
ResponderExcluir@craftnicely, boa, boa... preciso pensar então no filhote novo que vou adotar. Ou então vou parar com isso e ficar com as velhas mesmo, pra evitar a dor da perda novamente daqui a dez anos.
ResponderExcluirAOP é uma solução pra linguagens pouco expressivas ou rígidas demais, qualquer linguagem que tenha open-classes e que seja simples de se redefinir métodos e operadores vive muito bem sem AOP.
ResponderExcluirA idéia é bem interessante, mas no mundo das linguagens dinâmicas e da metaprogramação é uma coisa completamente desnecessária.