Balaio Tecnológico: Um novo paradigma: Programação Orientada a Aspectos

As ferramentas de modelagem de sistemas disponíveis para os Arquitetos de Software evoluem em paralelo com as técnicas de programação - quando um conceito é introduzido numa ferramenta, linguagens de programação rapidamente o incorporam também. Nos tempos em que o DFD (Diagrama de Fluxo de Dados) reinava, a programação de computadores era majoritariamente procedural. Isto é, os programas eram construídos com instruções sequenciais que emulavam o fluxo de dados definido pelo Diagrama, utilizando linguagens como o COBOL, Clipper ou Pascal. Hoje, as linguagems de programação comerciais mais usadas são calcadas no conceito de classes - Java, .Net, Delphi, etc. - e os sistemas são modelados frequentemente usando Diagramas de Classes e outras ferramentas que constituem a UML (Unified Modeling Language).

Essa forma de trabalho, no entanto, obriga o projetista a estabelecer relações entre certas classes que possuem pouco ou nada em comum, resultando em modelagens por vezes confusas, complicadas de se dar manutenção. Para ilustrar essa questão, imagine que você está modelando um sistema com operações que serão tratadas como transações no banco de dados.

Neste sistema, haverá operações para movimentação de estoque (com saída de quantidade de um depósito e a respectiva entrada no depósito destino), para registrar contabilizações (envolvendo uma ou mais contas contábeis para débito e crédito) e para efetuar pagamentos a fornecedores. Distingue-se neste cenário a necessidade de modelagem de diversas classes de objetos: item de estoque, conta contábil, movimento de estoque, contabilização, fornecedor, entre outros. Há ainda claramente uma entidade que deve controlar as transações no banco de dados para garantir que as alterações comandadas numa operação sejam tratadas como um bloco único. Embora nada tenham em comum, tanto movimentos de estoque quanto pagamentos a fornecedores devem ser contabilizados. Um diagrama de classes que ilustre essas relações ficará confuso por misturar conceitos de movimentação de itens e de pagamentos. A situação tende a piorar se surgirem outras operações que precisem ser contabilizadas. E do ponto de vista da programação, modificações na classe de contabilização afetarão todas as outras classes, exigindo que estas também sejam revisadas.

Recursos que permeiam várias classes de um sistema, vinculando mesmo aquelas que implementam regras conceitualmente distantes, são chamados de cross-cutting. Outros exemplos de recursos assim: criação de logs de operações, auditoria em alteração de dados, níveis de permissão de acesso a dados, autorização para executar operações, tratamento de exceções, etc. Melhorar a solução para esse tipo de recurso é a proposta da Programação Orientada a Aspectos (POA), onde o código que implementa os recursos cross-cutting são retirados das classes de negócio e inseridos em módulos próprios - os Aspectos. O código das regras de negócio fica mais limpo e alterações no funcionamento dos recursos cross-cutting passam a ser centralizadas no Aspecto.

A POA depende ainda de um mecanismo que permita vincular a execução dos códigos do Aspecto à execução das regras de negócio. A solução proposta pela POA é centrado no modelo de pontos de ligação (Join Points). Tal modelo é definido por 3 características: o momento em que o código poderá ser executado - chamado de join point -, uma forma de especificar esses momentos e uma forma de especificar o código que deve ser executado em cada momento.

Um ponto de ligação pode ser encarado como um evento que ocorre no código da regra de negócio - marcado pela execução de um determinado método ou pela alteração no valor de uma propriedade, por exemplo. Criar pontos de ligação significa, portanto, indicar quais desses eventos devem ser monitorados pelo Aspecto, usando para isso estruturas chamadas de pointcuts. Os pointcuts se valem de uma sintaxe especial para possibilitar a indicação de quais métodos e propriedades dispararão a execução do código relativo a um ponto de ligação. Ao código que será executado pelo Aspecto quando um ponto de ligação é encontrado dá-se o nome de Advice.

Assim como as Classes, Aspectos também podem conter variáveis internas (membros) e ter heranças para especializar seu comportamento, adequando-o a uma função mais específica. Voltando ao exemplo das operações dado no início deste post, uma solução usando Aspectos seria criar um Aspecto base para tratar transações com o banco de dados. Isso implica a criação de um ponto de ligação para apontar o início da função que realiza a operação, momento em que o advice desse ponto de ligação deve tomar providências para garantir a existência de uma transação no banco de dados. Outro ponto, ao final da operação, deve encerrar a transação. Para cuidar das transações que precisem ser contabilizadas faríamos uma herança desse Aspecto e introduziríamos o código necessário num dos pontos de ligação já estabelecidos. Nesta herança, indicaríamos como pointcuts apenas as classes expressando regras passíveis de serem contabilizadas.

A experiência mais bem sucedida para popularização da POA por enquanto é uma extensão da linguagem Java criada pelo Centro de Pesquisas da Xerox que tem o nome de AspectJ. Trata-se de um projeto open source disponível na Fundação Eclipse. Há ainda algumas bibliotecas voltadas para C#, disponíveis na forma de frameworks. O Delphi Prism - IDE para programação na plataforma .NET usando a linguagem Delphi - incorporou uma implementação para uso de POA em sua versão 2010 usando para isso recursos do próprio .NET. Veja aqui um exemplo de uso com a sintaxe do Delphi.

Tudo o que foi apresentado aqui não poderia ser resolvido apenas com uso de classes? Sim, poderia. Poderíamos até mesmo implementar tudo em uma solução exclusivamente procedural, se desejássemos. O ponto aqui é que as ferramentas até então existentes podem ser melhoradas para resolverem de forma mais eficiente determinados problemas. Uma nova filosofia está sendo amadurecida no campo da análise de sistemas e da programação e, mais cedo ou mais tarde, as linguagens também terão que evoluir para acompanhá-la consistentemente.