A programação orientada a aspectos é inadequada?

Com tudo o que aprendi sobre "Programação Orientada a Aspectos" ou "Desenvolvimento de Software Orientado a Aspectos", rotulá-la como paradigma ou metodologia de programação parece imprecisa. Pelo que sei, não é uma técnica fundamental para a programação.

Para definir o significado de "paradigma" e "metodologia", consulte as seguintes definições do American Heritage Dictionary. Compare quão bem ou mal a "Programação Orientada a Objetos" se aplica a cada um versus o quão bem a AOP se encaixa.

Paradigma: Um conjunto de suposições, conceitos, valores e práticas que constituem uma maneira de ver a realidade da comunidade que os compartilha, especialmente em uma disciplina intelectual.

Metodologia: Um conjunto de práticas, procedimentos e regras usadas por quem trabalha em uma disciplina ou se envolve em uma investigação; um conjunto de métodos de trabalho.

"Medicina baseada em evidências" satisfaz a definição de paradigma, mas "medicina baseada em histerectomia" seria um nome impróprio porque o espaço do problema é muito estreito.

Estou tendo a impressão de que AOP pode ser mal nomeado porque, com base no sufixo "programação orientada", a AOP alega ser tanto um paradigma quanto uma metodologia da mesma maneira que "Programação Orientada a Objetos".

Ambos os termos (paradigma e metodologia) indicam uma técnica fundamental, onde o que entendo sobre aspectos é uma tecnologia para resolver um escopo estreito de problemas, talvez comparável em magnitude à característica variável estática de Java.

Se é verdade que aspectos resolvem um conjunto restrito de problemas e AOP não é um nome impróprio, então por que todas as técnicas de programação não deveriam receber o sufixo "programação orientada", como "programação orientada a herança", "programação orientada a herança"? programação orientada "ou" programação orientada a escopo? "

Eu acho que essa é uma questão realmente duvidosa, porque a definição de uma "metodologia" e "paradigma" e "programação orientada" é potencialmente um pouco frouxa nesse contexto, mas vou interpretar o advogado do diabo e seguir com " sim, é um nome impróprio ".

Mesmo se você não usasse os recursos AOP ou AOP para resolver um problema, ainda estaria pensando nesses aspectos - você pode tê-los escritos como documentação em algum lugar ou pode usar um gerador de código - de qualquer maneira, o conceito de aspectos ainda está lá. Isso também pode combinar com qualquer paradigma; embora fosse muito feio, você ainda pode fazer POO em C.

Então, isso não significa que a AOP é tão metodologia quanto a OOP? Eu acho que há mais do que isso.

O motivo é que uma metodologia oferece solução para um tipo específico de problema . Você não usa mais de uma metodologia para resolver um problema conceitual, mesmo que você possa usar duas ou mais no esquema maior. Você pode usar OOP e procedural para escrever uma interface do usuário de entrada de dados, mas está usando apenas OOP para descrever a estrutura abstrata da interface do usuário e está usando apenas procedimentos (com mais precisão, métodos) para descrever seu comportamento. Nos constituintes principais de um problema, as metodologias são mutuamente exclusivas - e a AOP ainda pode participar da solução de um problema com código funcional, OOP ou procedural.

AOP resolve problemas no sentido de que reduz a quantidade de código repetido, mas isso está dentro da descrição do trabalho de um recurso de idioma. Você realmente não resolveu nenhum problema real conceitualmente dizendo que conseguirá que o compilador ou o tempo de execução injete algum código que não foi necessário escrever explicitamente; você acabou de tornar seu código um pouco mais organizado. Declarar que "todas as minhas funções registrarão seus horários de início e término" não é uma solução para um problema; é apenas uma declaração do problema.

Eu acho que seria mais apropriado para eles simplesmente serem chamados de "Aspectos", como um recurso de linguagem.

Todas as metodologias de desenvolvimento são apenas maneiras de pensar sobre a organização do código. Cada metodologia de desenvolvimento pode produzir código de aparência muito diferente ou pode produzir código semelhante. Eles também podem exigir bibliotecas ou recursos de idioma para suporte.

Em C ++, por exemplo, o AOP é normalmente implementado usando classes de características e polimorfismo em tempo de compilação. Não é uma "característica" da linguagem - você cria os vários aspectos do seu tipo e os combina como quiser com modelos.

Em linguagens como Java, que não têm algo parecido com modelos, você acaba precisando usar recursos de linguagem dedicados fornecidos por pré-processadores (por exemplo AspectJ) para programar de maneira orientada a aspectos, simplesmente porque a linguagem original não tem a capacidade de implementação da verdadeira AOP.

Como resultado, os programas de AOP parecerão muito diferentes em C ++ em comparação com Java - mas o mais importante é como o programador está pensando em seu design, não em como o código se parece.

Portanto, AOP certamente é uma metodologia de desenvolvimento.

Há duas coisas em jogo aqui - paradigma de programação versus metodologia de desenvolvimento de software .

Sim, a programação orientada a aspectos é um paradigma de programação. Ele aproveita certos recursos de idioma para representar as construções necessárias para executar uma tarefa ou tornar o código mais legível. É uma técnica que pode ser empregada por um programador. Muitas vezes, você vê o AOP usado ao lado da Programação Orientada a Objetos para remover preocupações transversais. No entanto, você pode implementar programação orientada a aspectos além de uma linguagem funcional. Não é necessariamente um paradigma inteiramente novo, mas uma extensão ao OOP e à programação funcional para aliviar problemas conhecidos. A principal razão pela qual acredito que deve ser considerado um paradigma é que ele muda a maneira como você pensa em encontrar uma solução para o problema. Assim como programação funcional, programação procedural, programação lógica e programação orientada a objetos, todas têm soluções drasticamente diferentes para o mesmo problema, a programação orientada a aspectos acrescenta outra solução ao conjunto de problemas.

Não, a programação orientada a aspectos não é uma metodologia de desenvolvimento. Uma metodologia de desenvolvimento é uma estrutura que você pode usar para criar um sistema de software. Ele especifica quais tarefas são executadas e como são executadas, desde os requisitos até o final da vida útil. AOP não diz nada sobre isso. No entanto, alguns paradigmas de programação levaram a abordagens de metodologia de desenvolvimento para o ciclo de vida do software. Havia uma abordagem chamada Engenharia de Software Orientada a Objetos, desenvolvida por Ivar Jacobsonque especificou um ciclo de vida completo para projetar e desenvolver sistemas orientados a objetos, mas caiu em desuso e foi substituído pela UML e pelo Rational Unified Process. Sinceramente, não vejo a AOP influenciando as metodologias da mesma maneira que a OOP. De fato, apenas olhar para as tendências parece indicar que as metodologias devem transcender a linguagem e os paradigmas usados ​​para construir o software. Pode haver técnicas de modelagem e vocabulário focados na AOP usados ​​durante o design e desenvolvimento, mas não vejo uma metodologia completa centrada na AOP.