fbpx

Boas práticas que ajudam a escrever métodos melhores

Métodos com muitas responsabilidades

Métodos ou funções com muitas responsabilidades são vilões que deixam o código mais difícil de entender. Neste artigo você vai conhecer algumas práticas que vão lhe ajudar a escrever métodos mais fáceis de manter.

A raíz de todos os males

Quantas vezes você bateu os olhos em algum método e levou minutos para entender o que ele fazia?

Esses dias estava revirando umas pastas antigas no meu HD e encontrei um programa que escrevi quando ainda estava aprendendo a programar. O programa tinha sido escrito em Clipper, linguagem puramente estruturada. Fiquei por alguns minutos lendo aquela infinidade de linhas e me perguntando: como eu conseguia manter isso?

Eram tantas linhas de código que dez sequências de Page Down não foram suficientes para chegar até o fim da função. A rotina fazia todo tipo de coisa, que ia desde mostrar alguma coisa na tela até enviar comando de baixo nível para imprimir um relatório.

Muito da nossa cultura de escrever métodos enormes é por não termos aprendido Orientação a Objetos do jeito certo.

Nós aprendemos a programar por um paradigma de programação estruturada, escrevendo tudo que o programa precisa fazer em métodos globais e, do dia para noite, mudamos para um paradigma que foi arquitetado para separar conceitos e delimitar estruturas.

Na faculdade, uma das primeiras matérias que aprendemos é escrever algoritmos procedimentais em pseudocódigo. Entendo que simplifica o aprendizado, mas contrário a isso, o aluno não tem a visão compartimentada que a Orientação a Objetos permite.

Pensando nisso, o primeiro conselho para quem está começando a programar, não importa o paradigma, é sobre métodos e funções. Eles devem fazer apenas uma coisa e fazê-la bem.

Responsabilidade única

Quando um método possui mais de uma responsabilidade, fica difícil de entender, consequentemente, mais difícil de manter. Se um método precisa executar mais de uma tarefa, é muito provável que ela esteja precisando dar luz a outro método.

O novo método gerado será uma ótima oportunidade para tornar a rotina mais descritiva. Já que você precisará escolher um nome para ele, por quê não designar um nome que revela exatamente aquilo que ele faz?

Se fosse dar uma única dica sobre responsabilidade única, diria:

Evite estruturas condicionais complexas como if-else aninhados e switch-case.

Essas estruturas levam a funções com múltiplas responsabilidades. Condicionais complexas violam dois princípios clássicos de POO: Princípio da Responsabilidade Única (SRP) e Princípio (OCP) Aberto e Fechado.
Ambos são fundamentais para manter os componentes do sistema independentes, extensíveis e reutilizáveis.

Nível de abstração por método

Outra dica é garantir que todos os métodos sejam chamados por outros métodos no mesmo nível de abstração. Quando as chamadas de um método estão no mesmo nível, fica fácil entender quais tarefas ele está executando.

Por exemplo, imagine uma função para imprimir um relatório de vendas, onde você deve exibir cabeçalho, conteúdo e rodapé. Você acha essa leitura fluída?

void ImprimirRelatorioDeVendas()
{
   var totalGeral = 0;

   ImprimirCabecalho();

   foreach (var item in itens)
   {
      Console.WriteLine($"Produto: { item } - Total: { item.Total }");
      totalGeral += item.Total;
   }

   Console.WriteLine($"Total Geral: { totalGeral }");
}

E agora, veja se fica mais clara a leitura?

void ImprimirRelatorioDeVendas()
{
   ImprimirCabecalho();
   ImprimirConteudo();
   ImprimirRodape();
}

Leitura do código de cima para baixo

Grave essa frase: escreva seu código como se estivesse escrevendo um livro.

Uma história narra uma sequência ordenada de acontecimentos; com início, meio e fim. Quando você estiver codificando, se imagine escrevendo um conto vitoriano, com um desfecho feliz, onde o mocinho salva a donzela, se casam e têm filhos parecidos.

Isso vai facilitar MUITO a vida do próximo programador que pegar seu código para ler.

No nosso exemplo do relatório de vendas, fazendo uma leitura step down, ou seja, sempre partindo do maior nível para o menor nível, ficaria fácil ler as sentenças:

Comece imprimindo o cabeçalho, depois o conteúdo e por último o rodapé.

Use nomes descritivos

Você sabe quando está trabalhando com um código limpo quando cada rotina é exatamente aquilo que você espera. Metade da batalha da luta por um código limpo está na escolha de bons nomes para pequenas funções que fazem só uma coisa.

Não tenha medo de nomes longos em funções. Um longo nome descritivo é melhor que um nome enigmático ou um longo descritivo comentário.

Se você quer saber mais sobre definição de bons nomes, leia também o artigo A importância dos nomes para um código limpo.

Até a próxima!

Receba meu conteúdo no Telegram

Se você deseja receber outros conteúdos direto no seu celular, entre no meu canal no Telegram.
Lá eu compartilho dicas para você dominar definitivamente a escrita do código limpo.

Hey,

o que você achou deste conteúdo? Conte nos comentários.

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *