ti-enxame.com

Que alternativas existem para preocupações transversais além da programação orientada a aspectos?

A programação orientada a aspectos promete lidar com preocupações transversais, mas ainda não estou completamente vendida. Houve outras tentativas de lidar com esse problema?

20
Casebash

Quando possível, você pode encapsular preocupações transversais em módulos separados que são usados ​​em todo o aplicativo por injeção de dependência. Isso permite dissociar um pouco a implementação da preocupação transversal do seu uso em todo o código.

Isso nem sempre funciona com elegância. Essa é a razão pela qual as pessoas estão tentando resolver o problema com coisas como AOP.

8
Fishtoaster

Duas outras opções que ainda não foram exploradas:

Programação Funcional com Mônadas e Setas

Em FP, você representa uma preocupação transversal como qualquer outra coisa: como algo que você transmite em uma chamada de função. Como isso explicitamente se torna tedioso, você pode usar Mônadas (ou talvez Flechas)) para ocultar as informações extras que estão sendo repassadas.

O exemplo mais comum da AOP é o log. Com as Mônadas, você criaria uma mônada "Logger" que mantém uma lista de mensagens. Quaisquer funções que você executa através do LoggerMonad têm a capacidade de postar uma mensagem de log. Com o Arrows, você modelaria todo o fluxo de dados do aplicativo e trabalharia uma rotina de logon no modelo, quando apropriado. Eu acho que. As setas são bem complexas.

Programação baseada em entidade/componente

Algo que eu tenho pesquisado e experimentado para um mecanismo de jogo. Em vez de "objetos", como no OOP, você decompõe tudo em pacotes de dados (componentes) e serviços que operam sobre um tipo de componente. Os componentes são agrupados por IDs comuns, como em um banco de dados relacional, e os grupos de componentes vinculados são as Entidades. Para adicionar o log em um sistema desse tipo, você adicionaria um novo serviço de log, os gatilhos com base nos componentes que passam por ele.

Ambos os métodos permitem trabalhar com facilidade uma mudança transversal com muita facilidade, mas ambos são modelos de arquitetura de alto nível. Então você provavelmente precisaria usá-los desde o início. O modelo de componentes pode, teoricamente, ser trabalhado em um sistema existente OOP. Acho que as mônadas também poderiam ser, se a sua linguagem for suficientemente poderosa.

6
CodexArcanum

Existem várias maneiras de resolver os problemas das preocupações transversais:

  • Use melhores padrões de design, expressões idiomáticas ou mecanismos de abstração : o código pode ser transversal, embora possa ser modularizado. Para manter o código, você precisará refatorar para usar a técnica de design que pode modularizá-lo. Essa refatoração pode introduzir cortes transversais de um tipo diferente, mas, esperançosamente, quais cortes transversais são estáveis ​​e que provavelmente não serão alterados.

  • Desenvolva recursos de idioma mais avançados : Muitas manifestações de crosscutting podem ser resolvidas por meio de melhores mecanismos de abstração e, às vezes, novos recursos de idioma são necessários. Por exemplo, linguagens mais avançadas que incluem recursos funcionais e orientados a objetos geralmente não empregam tantos padrões de design, porque não são necessários. Observe que os próprios padrões de design podem ter natureza cruzada, porque descrevem os papéis de vários objetos e classes diferentes. Em Java, a reflexão geralmente pode ser usada em vez de um aspecto, embora a um custo de tempo de execução mais alto. Por exemplo, usando a reflexão, você pode suportar o padrão de visitante em centenas de classes com apenas algumas linhas de código. A biblioteca de DJ da Northeastern é uma solução reflexiva que faz exatamente isso. Mixins são uma técnica poderosa disponível em C++ (mas não em Java) e podem fornecer alguns dos mesmos casos de uso que um aspecto.

  • Forneça melhor suporte à ferramenta : Técnicas como usar grep e executar operações de refatoração podem lidar com problemas relacionados ao código de corte transversal. Por exemplo, o nome de um método declarado em uma interface pode atravessar o programa. (Observe a diferença técnica aqui: é o nome do método, e não a implementação do método, que se cruza.) Isso geralmente não é um problema em um IDE como o Eclipse, onde você pode usar o "renomear refatoração" para alterar todos os locais em seu código que usam o nome. Dessa forma, é possível não precisar de recursos de linguagem quando o ambiente de programação é expressivo o suficiente para você.

  • Usar idiomas específicos do domínio : os idiomas de aspecto anteriores, anteriores ao AspectJ, eram específicos do domínio e aplicados a apenas alguns problemas, como sincronização de encadeamento ou análise de fluxo de dados para combinar eficientemente composições de funções. Essas linguagens eram experimentais, mas pareciam muito bem-sucedidas em modularizar preocupações que, de outra forma, eram transversais.

  • Use técnicas de programação generativa : subir para o nível meta pode ser considerado uma técnica de implementação para programação orientada a aspectos, mas é uma área grande o suficiente para transcender aspectos simples. Técnicas generativas (em que um programa gera código-fonte para outro programa) também estão relacionadas a idiomas específicos do domínio.

Para tudo isso, acho que estudar AOP é apropriado. AOP pode ajudá-lo a expandir suas concepções de código, mesmo se você não usar uma linguagem AOP.

3
Macneil

em geral etiquetando elementos de código com um recurso declarativo, mas especificamente o sistema de Atributos no mundo C # /. NET/Mono.

2
mumtaz

Não sou especialista em AOP, mas ao ler sobre isso ao longo dos anos, sempre pareceu uma forma mais fraca do metaprogramação oferecida pelo LISP , especialmente partes como seu protocolo de metaobjetos.

Isso não deve surpreender, suponho: Gregor Kiczales foi um dos autores do AMOP e depois escreveu o AspectJ para Java!

2
Ken