pequenas linhas de código – extrair método

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.

  1. Pronto, já fiz funcionar.
  2. 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[bb], do Martin Fowler[bb] 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.

Advertisements

8 thoughts on “pequenas linhas de código – extrair método

  1. 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.

    • 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

    • 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.

      • 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

      • 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.

  2. 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s