Orientação a Aspectos (ASPECT J)

Programação Arquitetura
#1

Boa tarde , Pessoal.

Estou iniciando em um projeto de grande porte bancário, e gostaria de saber a experiência de vocês em relação ao Uso da Orientação a Aspecto, gostaria de saber as vantagens e desvantagens do uso em programação orientado a obejto.

é viavél empregar esse tipo de aspecto?

Obrigado a todos.

#2

Cara to fazendo o meu TCC sobre isto e acho que é muito bom, precisa ver se o pessoal da equipe conhece, se bem que a curva de aprendizado é bem pequena, você quer colocar o AspectJ para trabalhar qual responsabilidade ?

#3

Deixa eu aproveitar o ensejo e perguntar:

AspectJ é sinônimo de Spring?

#4

Também estou desenvolvendo meu TCC e estou usando o AspectJ, realmente é bem rápido de aprender apesar de ser uma forma de pensar bem diferente.

[quote=andredecotia]Deixa eu aproveitar o ensejo e perguntar:

AspectJ é sinônimo de Spring?[/quote]

Não, AspectJ é uma linguagem de programação criada para ser utilizada em conjunto com Java.

#5

Não achei uma forma tão diferente não… ele visa a separação de responsabilidades que a OO visa mas tem dificuldade

#6

A programação a aspectos separa responsabilidades como OO, mas na prática a ideia é remover do código partes que são necessárias para a aplicação mas não tem necessáriamente relação com a lógica daquele metodo ou função.

Um exemplo simples é a adição de log, temos logs no código pois ele é necessário mas não tem relação especifica com a lógica a ser executada.

Na prática mesmo, no seu dia a dia, vai depender da ferramenta de aspecto que você escolher pois elas trabalham de maneira diferente, algumas necessitam de alteração nas suas classes (definição de pontos de corte) outros como o Spring se utiliza de um proxy dynamico para que algo seja executado antes ou depois do seu metodo.

Por cima, mas assim bem por cima mesmo, é algo assim:


// Estou inventando essa sintax apenas pro exemplo

public void doStuff(){

  # Log:inicio

   System.out.prinln("Oi!");

  # Log:fim

}

No codigo acima criamos um metodo e definimos dois pontos de corte, um “Log:inicio” e outro “Log:fim”, poderiamos chamar de dois aspectos sendo o inicio e o fim de metodos.

Ai criamos o seguinte pedaço codigo em outro arquivo:

# Log:inicio
System.out.println("iniciou o metodo");

e esse outro tb:

# Log:fim
System.out.println("finalizou o metodo");

Na sequencia utilizamos um compilador de aspectos que mescla todos os arquivos (e já compila o class):

public void doStuff(){

   System.out.println("iniciou o metodo");

   System.out.prinln("Oi!");

   System.out.println("finalizou o metodo");

}

Com isso, caso queiramos mudar o esquema de log do sistema inteiro apenas alteramos os aspectos, e eles serão alterados em todos os pontos de corte.

Outra caso pratico seria utililizar aspectos para demarcacao de transacao (que alias, eh o unico que eu uso mesmo).

Como minha aplicação usa Spring o que fazemos é definir quais os metodos terão

    <!-- definimos os transaction manager -->
    <tx:advice id="txAdvice" transaction-manager="txManager">
        <tx:attributes>
            <tx:method name="*" rollback-for="DataServiceException"/>
        </tx:attributes>
    </tx:advice>

    <!-- definimos os point cuts por pacote, classe e metodo -->
    <aop:config>
        <aop:pointcut id="serviceOperation" expression="execution(* br.com.acme.calculadora.dao..*.*(..))"/>
        <aop:advisor advice-ref="txAdvice" pointcut-ref="serviceOperation"/>
    </aop:config>

Quando um bean que tenha uma classe do pacote br.com.acme.calculadora.dao for injetado o Spring insere um proxy dynamico para ele, ai quando os metodos forem chamados chamados ele cria uma transação.

Eu particularmente nao gosto muito de magia negra, prefiro o codigo mais linear e facil e entender, minha experiencia pessoal nao foi das melhores, tive um monte de problemas usando aspectos em projetos e hoje soh uso para transacoes com Spring.

Aqui tem uma boa explicação com exemplos:

Abraço,

#7