em refatorações convencionais aplicadas a sistemas OO, porém elas consideram que aspectos podem estar ligados aos elementos OO. Assim, se os elementos OO forem modificados, os aspectos relacionados a eles podem se tornar inconsistentes. Dessa forma, há a necessidade de conhecer os aspectos existentes no sistema para poder refatorá-los juntamente com os elementos OO. Refatorações desse tipo foram inicialmente identificadas e apresentadas por Iwamoto e Zhao (Iwamoto e Zhao, 2003) e Hanenberg et al. (2003).
Iwamoto e Zhao (2003) apresentaram um estudo sobre impacto que as refatorações OO propostas por Fowler et al. (1999) poderiam exercer sobre as construções orientadas a aspectos relacionadas aos elementos refatorados. Na Tabela 3.2 um subconjunto das refatorações de Fowler et al. é apresentado, indicando, em fundo cinza, as refatorações que podem ser aplicadas em um sistema OA sem que isso afete os aspectos existentes nesse sistema. As demais refatorações (em fundo branco), quando aplicadas, podem exercer impacto nos aspectos, ou seja, elas podem alterar a semântica dos aspectos relacionados aos elementos a serem refatorados.
Tabela 3.2 – Refatorações OO propostas por Fowler et al., (1999).
Refatorações OO
Add Parameter Encapsulate Downcast Extract Class Extract Interface Extract Method Extract Superclass Extract Subclass Inline Class
Hide Method Inline Temp
Inline Method Move Field
Introduce Explaining Variable Move Setting Method Move Method Pull Up Constructor Parameterize Method Pull Up Method Pull Up Field Push Down Method Push Down Field Replace Array with Object Rename Method Replace Exception with Test
Replace Conditional with Polymorphism Replace Nested Conditional with Guarddd Clauses Replace Magic Number with Symbolic Constant Replace Temp with Query
Replace Parameter with Explicit Methods Set Encapsulate Field Remove Parameter
De acordo com a Tabela 3.2, nota-se que apenas 3 das 31 refatorações OO listadas não possuem impacto sobre construções OA. Assim, há a necessidade de
estender as demais 28 refatorações para que elas possam ser aplicadas em sistemas OA. Por exemplo, na Figura 3.6 é apresentado o código do aspecto LoggingAccountAspect, responsável por capturar as chamadas ao método withdraw() da classe Account (Figura 3.2) e imprimir a mensagem “Withdrawing...” na tela, antes da execução desse método.
1 public aspect LoggingAccountAspect {
2 pointcut withdrawMethod(): call(void Account.withdraw(..)); 3 before()withdrawMethod () {
4 System.out.println(“Withdrawing...”); 5 }
6 }
Figura 3.6 - Código fonte do Aspect LoggingAccountAspect.
Se a refatoração Rename Method (Fowler et al., 1999) for aplicada ao código da classe Account para modificar o nome do método withdraw() para getMoney() o aspecto LoggingAccountAspect e seu conjunto de junção withdrawMethod() ficarão inconsistente e seu comportamento será alterado. Assim, quando há existência de aspectos no sistema, a aplicação de refatorações como Rename
Method deve levar em consideração não somente as construções OO, mas também
as possíveis construções OA que podem estar relacionadas aos elementos OO refatorados. Na Figura 3.7 é apresentado o código fonte do aspecto LoggingAccountAspect refatorado em decorrência da modificação do nome do método withdraw() da classe Account para getMoney(). Na linha 2 é apresentado o trecho de código refatorado após a aplicação da refatoração Rename
Method adaptada para sistemas OA. Nesse caso, o conjunto de junção
withdrawMethod()foi modificado para capturar corretamente o método renomeado getMoney() da classe Account.
1 public aspect LoggingAccountAspect {
2 pointcut withdrawMethod(): call(void Account.getMoney(..)); 3 before()withdrawMethod () {
4 System.out.println(“Withdrawing...”); 5 }
6 }
Figura 3.7 - Código fonte do Aspect LoggingAccountAspect.
Segundo Hanenberg et al. (2003), a razão para a existência de conflitos entre refatorações OO e as características da POA é a própria natureza da especificação dos aspectos. Conforme foi explicado na Seção 2.2 sobre orientação a aspectos, aspectos interceptam pontos bem definidos no fluxo de execução de um programa (pontos de junção) que são especificados por conjuntos de junção em uma
linguagem OA. Como refatorações OO geralmente alteram a estrutura do código base (por exemplo, os identificadores de métodos, atributos, classes e interfaces), os conjuntos de junção podem se tornar inconsistentes.
Com base no problema descrito acima e no trabalho de Opdyke (1992), Hanenberg et al. (2003) propuseram três condições necessárias para se garantir a preservação do comportamento externo (ou comportamento observável) de sistemas OA após a aplicação de refatorações. As condições propostas por Opdyke foram apresentadas a fim de orientar a verificação da preservação do comportamento de um software OO após refatorações. Em Hanenberg et al., o conjunto dessas condições foi estendido, acrescentando-se três novas condições para o contexto de software OA:
1) A quantidade de pontos de junção que são capturados por um dado conjunto de junção não deve ser modificado após a refatoração;
2) Os pontos de junção que são capturados por um dado conjunto de junção devem ter uma posição equivalente dentro do fluxo de controle do sistema se comparado ao estado anterior à refatoração.
3) A informação dos pontos de junção oferecida por cada conjunto de junção não deve ser diminuída.
A primeira condição é necessária para garantir que os pontos de junção capturados por aspectos antes e após a refatoração são os mesmos. A segunda condição, por sua vez, garante que os pontos de junção capturados pelos conjuntos de junção após a refatoração tenham uma posição equivalente no fluxo de controle do sistema antes da refatoração. Por fim, a terceira condição tem como objetivo assegurar que a informação relacionada aos pontos de junção de cada conjunto de junção não deve ser enfraquecida, isto é, diminuída, em relação à informação antes da refatoração, caso haja alguma alteração nestes conjuntos.
Tanto o trabalho de Iwamoto e Zhao (2003) como o de Hanenberg et al. (2003) não apresentam ferramentas que apoiem a aplicação das refatorações propostas o que pode tornar custosa a tarefa de refatoração para sistemas OA de média e larga escala.