Para um programador preocupado com a qualidade do código existe um hábito que é o de olhar novamente para o código assim que ele esta pronto.
Queria pensar aqui um pouco sobre o que é estar pronto, mas resolvi reduzir o “pronto” para dois tipos.
- Pronto, já fiz funcionar.
- Pronto, esta funcionando da melhor maneira que posso imaginar no momento (sempre há um “re-olhar” para o código, eternamente).
O exemplo abaixo é bem curto. Uma classe chamada mensagem que contem somente seu construtor e um método que realiza duas tarefas, a de receber o texto da mensagem e gravar a mensagem no sistema SGDB. Esse é o exemplo de pronto do tipo 1.
Bem, o código funciona, provavelmente atende a necessidade do documento de requisição, mas temos algumas coisas que podem ser melhoradas, então vamos levar este código para o tipo de pronto 2.
Agora temos um código que considero melhor que o anterior, por pequenas coisas, mas acho.
A principal coisa é que cada método da classe agora tem uma única responsabilidade. Isso vai facilitar o tratamento de erro, a montagem de algoritmos complexos em que um objeto dessa classe esteja envolvido e reduz o uso de documentação inútil redundante. Por inútil entenda que agora você não vai precisar dizer o que um método faz. O nome do método já esta dizendo isso e você pode confiar nisso.
Se voce reparar no método setMensagemAndSave, vai ver que ele ficou mais claro, mais fácil de ler (se achar que o exemplo não demonstra isso, faça um esforço e imagine o mesmo exercício sendo praticado num método com um algoritmo complexo com umas 20 responsabilidades envolvidas e programadas diretamente ali, na função.
O nome desse pequeno refactoring é extrair método e é um dos apresentados no livroRefatoração, do Martin Fowler
e eu acho importante esse tipo de operação.
Como uma visão global, vale lembra que agora você pode atribuir uma nova mensagem e esperar para gravar em outro momento, que pode chegar ou não e que o método publico e publicado não teve seu algoritmo alterado, nem sumiu, nem nada desse tipo.
É isso ai, eu avisei que seriam….
Pequenas linhas de código.
wesley victhor mendes
09/04/2011 — 18:55
só tirar o “n” do operador throw…
…mas bacana. (:
Ivo Nascimento
09/04/2011 — 18:58
já tirei,
obrigado pelo aviso.
Alexandre Brina
10/04/2011 — 04:29
Off topic: eu tb misturo inglês com português nos nomes dos métodos, já tentei só inglês, só português, não fiquei feliz. Mas tb não gosto do mesclado, acho que é algo que tenho que conviver.
On topic: este é o mais importante refactoring dentre todos, um mundo se abriu quando o vi pela primeira vez no livro do Martin Fowler.
Ivo Nascimento
10/04/2011 — 08:27
Hahaha, nem reparei que tinha feito isso(misturado Ingles e portugues).
Não vejo problema. Semanticamente voce tem o mesmo resultado, mas não é mto meu costume não.
[]’s
Mario Arroyo
11/04/2011 — 11:45
Eu gosto bastante de deixar os nomes de classes, variáveis e métodos o mais parecidos possível com a linguagem falada com os especialistas do domínio da aplicação (que também deve ser refletida nos modelos do domínio, como diagramas de classe etc). Se eu converso em inglês com o cliente, isso reflete no meu código; se eu converso em português com o cliente, isso reflete no meu código. Comecei a botar isso em prática após a leitura do livro do Eric Evans e, nunca mais consegui deixar de lado. The power of the ubiquitous language.
Ivo Nascimento
11/04/2011 — 12:46
Muito bom esse seu ponto de vista. Isso é elevar a linguagem do dominio do problema ao máximo uso.
Vou refletir mais sobre isso.
valeu pelo comment.
[]’s
Mario Arroyo
12/04/2011 — 06:40
Pois é, existem muitas coisas interessantes relacionadas à “linguagem onipresente”. No livro Domain Driven-Design (DDD) do Eric Evans existe um capítulo inteiro dedicado somente a esse conceito.
Duodraco
10/04/2011 — 07:23
Bom artigo.
Introduzir métodos facilitadores são sempre uma boa prática.
Uma outra boa refatoração seria separar um objeto que mantém a informação necessária, a validando e tratando, e este servir de “Dependencia” de Informação (por exemplo, a Mensagem) para outro objeto que simplesmente executa o “salvarMensagem” (um MessageSaver num exemplo simples, ou criando data mappers, ou outro tipo de executor), que recebe o Mensagem, ou qualquer derivado e se encarrega de persistir a mensagem, seja no banco ou qualquer outra coisa.