Orientada aspecto vs programação orientada a objectos de programação

https://stackoverflow.com/questions/232884

04-07-2019
|

Pergunta

Como a maioria dos desenvolvedores aqui e em todo o mundo, tenho vindo a desenvolver sistemas de software usando programação orientada a objetos (OOP) técnicas por muitos anos. Então, quando eu li que a programação orientada a aspectos (AOP) resolve muitos dos problemas que OOP tradicional não resolver completamente ou diretamente, eu parar e pensar, é real?

Eu li um monte de informações tentando aprender as chaves desse paradigma AOP e estou no mesmo lugar, por isso, eu queria entender melhor seus benefícios no desenvolvimento de aplicações do mundo real.

Será que alguém tem a resposta?

Solução

Por "vs"? Não é "vs". Você pode usar Aspect Oriented Programming em combinação com programação funcional, mas também em combinação com Object Oriented um. Não é "vs", que é "Programação Orientada a Aspectos com Programação Orientada a Objetos".

Para mim AOP é algum tipo de "meta-programação". Tudo o que AOP não poderia também ser feito sem ele apenas adicionando mais código. AOP apenas poupa escrever este código.

Wikipedia tem um dos melhores exemplos para esta meta-programação. Suponha que você tenha uma classe gráfica com muitos "set ... ()" métodos. Após cada método set, os dados dos gráficos mudou, assim, os gráficos mudou e, portanto, os gráficos precisam ser atualizados na tela. Suponha que redesenhar os gráficos você deve chamar "Display.update ()". A abordagem clássica é a de resolver isso adicionando mais de código . No final de cada método set você escreve

void set...(...) {
    :
    :
    Display.update();
}

Se você tem 3 set-métodos, que não é um problema. Se você tiver 200 (hipotética), está ficando verdadeira dolorosa para adicionar este em todos os lugares. Além disso, sempre que você adicionar um novo set-método, você deve ter certeza de não esquecer de adicionar este para o final, caso contrário, você acabou de criar um bug.

AOP resolve este sem adicionar toneladas de código, em vez de adicionar um aspecto:

after() : set() {
   Display.update();
}

E é isso! Em vez de escrever o código de atualização, você simplesmente dizer ao sistema que depois de um set () pointcut foi alcançado, ele deve executar esse código e ele irá executar este código. Não há necessidade de atualizar 200 métodos, não há necessidade para se certificar de que você não se esqueça de adicionar este código em um novo set-método. Além disso, você só precisa de um pointcut:

pointcut set() : execution(* set*(*) ) && this(MyGraphicsClass) && within(com.company.*);

O que isso significa? Isso significa que se um método é chamado de "set *" (* significa qualquer nome pode seguir depois de conjunto), independentemente do que o método retorna (primeiro asterisco) ou quais os parâmetros que leva (terceiro asterisco) e que é um método de MyGraphicsClass e essa classe é parte do pacote "com.company. *", então este é um pointcut set (). E o nosso primeiro código diz " após a execução de qualquer método que é um pointcut set, execute o seguinte código".

Veja como AOP resolve elegantemente o problema aqui? Na verdade tudo descrito aqui pode ser feito em tempo de compilação. Um pré-processador AOP pode simplesmente modificar sua fonte (por exemplo, adicionando Display.update () ao final de cada método set-pointcut) antes mesmo de compilar a classe em si.

No entanto, este exemplo mostra também uma das grandes desvantagens de AOP. AOP está realmente fazendo algo que muitos programadores considerar um " Anti-Pattern ". O padrão exato é chamado de " acção a um distância".

Ação à distância é uma anti-padrão (um comum reconhecido erro) no qual o comportamento em uma parte de um programa varia muito com base em difícil ou impossível identificar operações em outra parte do programa.

Como um novato para um projeto, eu só poderia ler o código de qualquer set-método e considerá-lo quebrado, como parece não atualizar a exibição. Eu não veja por apenas olhando para o código de um set-método, que depois de ser executado, algum outro código irá "magicamente" ser executado para atualizar a exibição. Eu considero isso uma desvantagem séria! Ao fazer alterações em um método, bugs estranhos pode ser introduzido. Além disso compreender o fluxo de código de código onde certas coisas parecem funcionar corretamente, mas não são óbvias (como eu disse, eles apenas magicamente trabalho ... de alguma forma), é realmente difícil.

Atualização

Só para esclarecer que: Algumas pessoas podem ter a impressão de que estou dizendo AOP é algo ruim e não deve ser utilizado. Isso não é o que estou dizendo! AOP é realmente uma grande característica. Eu só dizer "Use-o com cuidado". AOP só irá causar problemas se você misturar up normalcódigo e AOP para o mesmo Aspect . No exemplo acima, temos o aspecto de atualizar os valores de um objeto gráfico e pintura do objeto atualizado. Isso é na verdade um único aspecto. Codificação metade do que como código normal ea outra metade do que como aspecto é o que acrescenta o problema.

Se você usar AOP para um aspecto completamente diferente, por exemplo, para registro, você não vai correr para o problema anti-padrão. Nesse caso, um novato para o projeto pode se perguntar "Onde fazer todas essas mensagens de log vem? Eu não vejo qualquer saída log no código", mas isso não é um problema enorme. Mudanças que ele faz para a lógica do programa dificilmente vai quebrar o recurso de log e as alterações feitas à facilidade log dificilmente vai quebrar a sua lógica do programa - estes aspectos são totalmente separados. Usando AOP para a exploração madeireira tem a vantagem de seu código de programa pode se concentrar totalmente em fazer o que ele deve fazer e você ainda pode ter o log sofisticado, sem ter o seu código a ser desordenado por centenas de mensagens de log em todos os lugares. Além disso, quando o novo código é introduzido, magicamente registrar mensagens irá aparecer no momento certo com o conteúdo certo. O programador novato pode não entender por que eles estão lá ou de onde vieram, mas uma vez que irá registrar a "coisa certa" no "momento certo", ele pode apenas aceitar alegremente o fato de que eles estão lá e passar para outra coisa .

Assim, um bom uso de AOP no meu exemplo seria sempre log ou nenhum valor foi atualizado através de um método set. Isso não vai criar um anti-padrão e quase nunca ser a causa de qualquer problema.

Pode-se dizer, se você pode facilmente abusar AOP para criar tantos problemas, é uma má idéia para usar tudo. No entanto, que a tecnologia não pode ser abusado? Você pode abusar de encapsulamento de dados, você pode abusar herança. Praticamente todas as tecnologias de programação útil pode ser abusado. Considere uma linguagem de programação tão limitada que só contém recursos que não podem ser abusadas; uma linguagem onde os recursos só podem ser utilizados como eles foram inicialmente destinados a ser utilizados. Tal linguagem seria tão limitado que é discutível se ele pode ser usado até mesmo para a programação do mundo real.

Outras dicas

OOP e AOP não são mutuamente exclusivas. AOP pode ser bom complemento para OOP. AOP é especialmente útil para a adição de código padrão como o registo, acompanhamento de desempenho, etc. aos métodos sem obstruir o código de método com este código padrão.

orientada a aspectos pogramming fornece uma boa maneira de implementar preocupações transversais como logging, segurança. Estes concers transversais são pedaços de lógica que têm de ser aplicadas em muitos lugares, mas na verdade não tem nada a ver com a lógica de negócios.

Você não deve ver AOP como uma substituição de OOP, mais como um bom add-on, que faz seu código mais limpo, fracamente acoplado e focado na lógica de negócios. Assim, através da aplicação de AOP você vai gt 2 principais benefícios:

A lógica para cada preocupação está agora em um só lugar, em vez de ser espalhados por toda a base de código.
aulas são mais limpo, uma vez que só contêm o código para a sua principal preocupação (ou funcionalidade do núcleo) e as preocupações secundárias foram movidos para aspectos.

Eu acho que não há uma resposta geral para esta questão, mas uma coisa a se notar é que AOP não substituir OOP mas acrescenta certa decomposição apresenta o endereço do chamado tirania a composição dominante ( 1 ) (ou transversais preocupações).

Ele certamente ajuda em certos casos, enquanto você está no controle das ferramentas e linguagens de usar para um projeto específico, mas também adiciona um novo nível de complexidade em relação a interação de aspectos e a necessidade de ferramentas adicionais, como o < a href = "http://www.eclipse.org/ajdt" rel = "nofollow noreferrer"> AJDT ainda compreender o seu programa.

Gregor Kiczales uma vez deu uma palestra introdutória interessante sobre AOP no Google Tech Talks que eu recomendo assistir: Aspect Oriented Programming:. Radical Research na modularidade

Antes de tudo AOP não irá substituir OOP. AOP estende OOP. As idéias e práticas de OOP permanecer relevante. Ter um bom design objeto provavelmente irá torná-lo mais fácil de estendê-lo com aspectos.

Eu acho que as ideias que AOP traz são importantes. Precisamos trabalhar para fora maneiras de implementar cross-cutting-preocupações sobre diferentes classes em seu programa sem ter que mudar-se as classes. Mas acho que o AOP irá eventualmente acaba de se tornar parte de outras ferramentas que usamos e não uma ferramenta ou técnica separado. Nós já vemos isso acontecer.

Um par de linguagens dinâmicas como Ruby e Python têm construções de linguagem como mixins que resolvem os mesmos problemas. Este parece muito com AOP, mas é melhor integrado na língua.

Spring and Castle e um par de outro quadro de injeção de dependência têm opções para adicionar comportamento para as classes que injectam. Esta é uma maneira de fazê-runtime-tecelagem e eu acho que isso tem um grande potencial.

Eu não acho que você vai ter que aprender um paradigma completamente novo para usar AOP. As ideias são interessantes, mas estão sendo lentamente absorvida por ferramentas e linguagens existentes. Basta ficar informado e experimentar essas ferramentas.

AOP é uma nova negociação paradigma de programação com este conceito. Um aspecto é uma entidade de software implementar uma parte específica não-funcional da aplicação.

Eu acho que este artigo é um bom lugar para começar com o Aspect Oriented Programming: http://www.jaftalks.com/wp/ index.php / introdução-a-orientada a aspectos-programação /

OOP é usado principalmente para organizar a sua lógica de negócios , enquanto AOP ajuda a organizar seus coisas não funcionais como Auditoria, Logging, gerenciamento de transações, segurança etc

Desta forma, você pode separar sua lógica de negócios com a lógica não-ficcional que faz código mais limpo.

vantagem Otter é que você pode aplicar o conselho (exemplo de auditoria) muito consistente sem implementar qualquer interface que dá grande flexibilidade para a modificação sem lógica de negócios tocar

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow