Opa! Pessoal! Dando continuidade a nossa série Refactoring, quando veremos mais uma situação onde devemos aplicar a técnica. A situação apresentada na série de hoje, normalmente acontece quando estamos realizando alterações constantes. Espero que gostem!
Lets go…
Posts relacionados:
Refatoração em código Java na prática – Nova Coluna Imasters!
Vantagens/Desvantagens e ferramentas
Refactoring e Manutenção de Software
Este post está dividido:
-
Motivação do uso da técnica
-
A mecânica para executar a técnica
-
Um exemplo
Obs.: O nome da técnica terá como referência o sugerido por Fowler. Claro que, você programador pode dar o nome que achar conveniente. Por boas práticas, dei preferência manter a nomeação de um dos pais da refatoração.
Técnica: Mover método
Como já dito, normalmente acontece uma situação para aplicar essa técnica, quando acontecem alterações constantes que acabam resultando nesse cenário. Algumas vezes, temos um método sendo utilizado por mais recursos de outras classes do que pela classe onde foi definido. Em situações como essa se deve mover o método a fim de adequar seu uso a classe.
Motivação
Mover métodos é uma prática comum da refatoração. Normalmente, movem-se métodos quando as classes têm comportamento demais ou estão colaborando entre si. Movendo alguns métodos, ficam mais claros os objetivos e as responsabilidades de cada classe. Um ponto importante é que os métodos da classe devem ser examinados antes de serem mudados. Deve-se procurar métodos que pareçam referenciar outros objetos mais do que a classe na qual está inserido. Após encontrar um método candidato, é necessário avaliar os métodos que ele chama e os métodos que o chamam a fim de definir com qual objeto o método interage mais.
Mecânica
A refatoração mover método foi executada com os passos a seguir:
a) examinar se os atributos da classe de origem são utilizados pelo método e se esses
devem ser movidos também;
b) procurar declarações dos métodos nas subclasses e superclasses da classe de
origem;
c) mover o método para a classe destino;
d) ajustar o método a fim de funcionar na nova classe;
e) compilar e testar;
f) caso o método seja removido da classe de origem, as referencias ao método
devem ser substituídas por referências de sua nova localidade;
g) compilar e testar.
Exemplo
O código code 1 apresenta um código não refatorado onde teremos diversos novos tipos de contas. Cada uma das quais com suas próprias regras para calcular o custo do saque a descoberto. Observe que na linha 3, o método cobrançaPorSaqueADescoberto está usando mais recursos de outra classe onde não foi definido.
1. class Conta . . .
2. private TipoConta tipo ;
3. double cobrancaPorSaqueADescoberto(){
4. if(tipo.ePremium()){
5. double resultado = 10;
6. if( diasDescorbetos > 7)
7. resultado += (diasDescorbetos – 7) *0.85;
8. return resultado;
9. }else return diasDescorbetos * 1.75;}
10.double tarifaBancaria(){
11. double resultado =4.5;
12.if(diasDecorbetos > 0)
13. resultado += cobrancaPorSaqueADescoberto();
14.return resultado}
code 1 – Método que tem recursos demais sobre outra classe (código não refatorado)
O code 2 apresenta o código refatorado onde o método (cobrancaPorSaqueADescoberto) foi transferido para a class TipoConta como pode ser visto na linha 2 à 13. A referência tipo foi removida na linha 4. Agora a class Conta retorna o método cobrancaPorSaqueADescoberto na linha 18. Veja a seguir como ficaram as classes:
1. class TipoConta …
2. double cobrancaPorSaqueADescoberto(int diasDescobertos){
3. if(ePremium()){
4. double resultado = 10;
5. if( diasDescorbetos > 7)
6. resultado += (diasDescorbetos – 7) *0.85;
7. return resultado;}
8. else return diasDescorbetos * 1.75;}
9. double tarifaBancaria(){
10. double resultado =4.5;
11.if(diasDecorbetos > 0)
12. resultado += cobrancaPorSaqueADescoberto();
13.return resultado;
14.}}
15.class Conta{
16.private TipoConta tipo ;
17.double cobrancaPorSaqueADescoberto(){
18.return tipo.cobrancaPorSaqueADescoberto(diasDescorbetos);}}
code 2 Movendo método para a classe onde está sendo mais utilizado
Agora o código está mais objetivo de na classe mais apropriada concorda? Bom, vou ficando por aqui! Espero que tenham gostando dessa série! E fica ai mais uma vez os efeitos que Refactoring causa dentro do ambiente de desenvolvimento. Um abraço a todos e até o próximo post! Have a nice weekend everybody 🙂
Clique na imagem para ampliar