Autor: camilolopes

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:

Refactoring Série 1

Refatoração em código Java na prática – Nova Coluna Imasters!

Refatoração

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 🙂

Salve! Salve! Pessoal! Antes de apresentar o primeiro post, quero dar um feliz ano novo a todos, com muita paz e saúde.

Durante o período de 30/12/08 à 04/01/09 que fiquei camilo-off, onde estava curtindo um pouco essas férias, fique pensando, qual será o primeiro post para 2009? Ai veio, “que tal completar aquela série refactoring 2008? Porém, com a parte prática conforme prometi”. Sendo assim, a promessa está sendo paga. Rs… Hoje vou mostrar algumas práticas de refactoring a nível de código. Claro que será em Java code, como dizem, será “mão na massa”. Veremos algumas situações que devemos aplicar a técnica quando estamos programando.

Para ficar mais emocionante coloquei o assunto em série, sendo esta, a primeira de outras que teremos. Um livro que recomendo para quem deseja estudar o assunto é o do Fowler, é realmente fantástico esse livro.

Lets go…

Link Recomendado

Refatoração

Vantagens/Desvantagens e ferramentas

Refactoring e Manutenção de Software

Refatoração em código Java na prática – Nova Coluna Imasters!

Obs.: serão apresentados apenas trechos de códigos referentes ao assunto. Não há necessidade de apresentar toda linha de códigos de uma classe, uma vez que estes não refletem no assunto em questão.

Para quem não lembra, o que é refactoring lá vai uma breve descrição. Para maiores informações sobre, basta acessar os links acima.

Breve descrição

Refactoring: é o processo de alterar um Software sem mudar seu comportamento. Um Software refatorado deve executar da mesma forma que antes da aplicação da técnica. A vantagem de aplicar essa técnica dentro do ambiente de produção é que ela promove um desenvolvimento rápido e facilita na manutenção do 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: Expressão Condicional

A situação para aplicar essa técnica, é algo bastante comum. Quem aqui nunca ouviu e/ou desenvolveu expressões condicionais retornando o mesmo resultado?

Ao se deparar com uma situação acima, temos que aplicar a técnica de refactoring para deixarmos o código mais limpo e facilitar o entendimento. Veja abaixo a real motivação para aplicação da técnica.

Motivação

Em alguns blocos de códigos é possível encontrar expressões condicionais remetendo a um mesmo resultado. Assim, condensar as expressões em apenas uma, pode ser considerado uma técnica de refatorar. Condensar as expressões condicionais é importante pelos seguintes motivos:

a) Primeiro: com apenas uma expressão condicional torna a verificação mais clara, mostrando o que está realmente executando uma única verificação. Ao contrário quando se tem condições separadas, onde transmite a impressão de ter verificações independentes.

b) Segundo: com as expressões condensadas, fica mais fácil de aplicar outras técnicas de refatoração, a partir do momento em que se têm códigos mais claros.

Mecânica

A mecânica da técnica de refatoração a seguir, é para uma situação semelhante ao code 1.

a) verificar se nenhuma das expressões condicionais causa efeito colateral, ou seja,

alteração em uma das mudanças faz o programa não funcionar como antes. Caso haja,

esse procedimento não deve ser executado;

b) substituir um conjunto de condicionais por apenas uma expressão condicional usando

operadores lógicos;

c) compilar e testar.

Exemplo

O code 1 apresenta expressões condicionais remetendo o mesmo resultado, conforme é apresentado nas linhas 2, 3 e 4, o que dificulta a leitura do código. Imagine isso com mais expressões, onde há mais linhas para serem compreendidas. O code 1 apresenta um código não refatorado.

…

1. double valorPorIncapacidade(){//calcular o valor incapacidade

2. if(_antiguidade <2) return 0;

3. if(_mesesIncapacitado > 12)return 0;

4. if(_eTempoParcial)return 0;}}

…

code 1 – Expressões condicionais que retornam o mesmo resultado. (Código não refatorado)

Código refatorado code 2 consolidou as expressões condicionais utilizando o operador “OU” para obter único resultado, como pode ser visto nas linhas 2 e 3.

1. double valorPorIncapacidade(){//calcular o valor por incapacidade

2. if((_antiguidade < 2)||(_mesesIncapacitado > 12)|| (_eTempoParcil))

3. return 0;

4. }

code 2 – Consolidar Expressão Condicional. (código refatorado)

Observe ambos os codes e veja à essência e os efeitos que a aplicação da técnica de refactoring promove. Qual código está mais fácil de ler? A manutenção se tornou mais fácil?

Muitas vezes estamos programando e não nos damos conta disso. Claro que isso pode parecer algo insignificante, pois, estamos aplicando a técnica em apenas 04 linhas de códigos. Mas, na prática sabemos que é comum encontrarmos expressões condicionais com mais de 20 linhas remetendo o mesmo resultado. Então a partir de agora ao identificar uma situação assim basta refatorar e tornar seu ambiente de produção mais saudável.

Vale salientar que a técnica de refatoração não é algo fechado, ou seja, ela não define quantas expressões condicionais são necessárias para aplicar a técnica. Isso tudo vai depender da equipe de desenvolvimento definir quando deve ser aplicada a técnica. Essa regra também vale para outras técnicas de refactoring.

Bom, vou ficando por aqui! Um abraço para todos! Espero que tenham gostado e até a próxima. Have a nice week, everybody!