REFACTORING – Caso Real e boas maneiras Parte IV (Keep Walking…)

Essa semana tive que resolver um bug na feature dos posts anteriores. Acabei esquecendo um caso que caia em uma Exception, mas não vamos tocar no assunto🙂.

O caso é o seguinte, como dito anteriormente, aconteceu que eu tive que manter esse código, corrigir a falha como dito anteriormente e porque não refatorar mais um pouco?

E o caso da refactoring de hoje, tem um tema central que é o uso excessivo de getters e setters (aquele mesmo que você usa, não sabe o porque, e todo mundo acha que está certo. Amém.).

Um amigo meu defende: “porque usar todos os atributos privados, se tem um método get e set para cada. Usa todos os atributos públicos e pronto. Muito mais elegante”. Bem, eu concordo e não concordo. O uso excessivo de getters e setters, no qual eu já defendi como correto(#fail pra mim), é prejudicial. Mesmo se você não precise, e não saiba o porque, você vai criar um. As vezes por costume, ou o framework usado no seu projeto obrigue. Mas enfim, vamos usá-los quando preciso, respeitando o encapsulamento. Fundamento da OO muitas vezes esquecido.

Então, como fazer? Como diz o Guilherme Silveira na palestra sobre design de código. No meu código, eu tenho um objeto que sempre terá um atributo. O que eu faço para que esse meu objeto sempre tenha esse atributo ao criá-lo? Colocar no construtor? Muito bem, é isso mesmo. Adicionando os atributos no construtor, muito dos setters serão inúteis, então só deletá-los.

Pois então vemos como ficou o nosso código. Focando no método carregar a lista de objetos para o relatório.

Repare em todos os setters que estão listados para “montar” o objeto, para então ser passado a lista. Repare que sempre eu passo mais um objeto do tipo ProdutividadeFisioterapeuta como parâmetro nos métodos, algo está errado. Enquanto na classe ProdutividadeFisioterapeuta.java está o clássico construtor sem parâmetros, chamando o método super() da classe Object. E repleta de getters e setters. Não vou listar a classe, mas acredite, eles estarão lá.

Pois então, vamos criar nosso construtor inteligente na classe ProdutividadeFisioterapeuta.java.

Perceba a clareza que ficou o nosso construtor em relação a bagunça anterior.

Vamos ver como ficou o método da listagem 1, após a refatoração.

Indo pro histórico do github, vemos ai o resultado. 42 linhas a menos e mais clareza no código.

E claro ia esquecendo do mais importante, retirar os setters inúteis. Após excluir os setters, substituí em outros locais do código onde eu os utilizava, como nos testes de integração da classe. Após o último commit:

Finalizando, como tenho dito, sempre você vai ter que manter seu código e se possível sempre tente melhorá-lo. Talvez um dia você olhe para o código e não encontre nada para melhorá-lo. Bem, eu nunca tive esse privilégio. Então é isso, mais um caso prático de como melhorar seu código. Excelente dica: Como não aprender OO com java. Excelente post da caelum.

Até mais e bons estudos.

3 Responses to REFACTORING – Caso Real e boas maneiras Parte IV (Keep Walking…)

  1. Rodrigo Oliveira disse:

    Excelente post, Yuri.

  2. Edson Marques disse:

    Show de bola cara! Muito bom!
    Mudou minha forma de ver os getters and setters.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: