Object Calisthenics: 9 regras para aperfeiçoar seus códigos

Espalhe a palavra!
  •  
  •  
  •  
  •  
  •  
  •  
  •  

É aqui que diferenciamos os programadores dos bons programadores.

Um código é muito mais do que apenas letras que executam funções definidas. Por acaso seu professor costumava dizer: “O caderno é o espelho do aluno”?

Pois é, cada vez mais percebo que essa frase é uma grande verdade. Porém aqui, é como se o caderno simbolizasse o código, e o aluno fosse como o programador.

Imagine o que seria de uma confeiteira se ela entregasse seus bolos de qualquer jeito, porém gostosos?

Hoje em dia existem milhões de Design Patterns, e aqui iremos abordar alguns que são fáceis de implementar ou que causam um grande impacto em seu mindset.

Neste artigo iremos falar sobre o Object Calisthenics que, em minha opinião, é o Design Pattern mais importante como pontapé inicial para um código perfeito e legível.

Object Calisthenics

O Object Calisthenics é uma série de boas práticas e regras de programação criadas pela comunidade de desenvolvedores Java, contendo apenas 9 regras fáceis que mantém uma boa organização e clareza para a compreensão de um código.

Primeira Regra: Apenas um nível de identação por método

Com certeza você já olhou para algum método gigante e se perguntou por onde começar, certo?

Seria um sonho entendermos rapidamente o que um método faz.

A ideia principal é que cada método faça apenas uma coisa. Desse modo facilitamos a leitura e a manutenção do código.

Você pode extrair comportamentos para outros métodos garantindo um único nível de identação. Fazendo isso, você também está aplicando o Extract Method Pattern.

 

Antes:

Depois:

Segunda Regra: Não use else

Com certeza a regra mais polêmica, porém acredito que seja a mais importante. O olhar assustador ou pensativo quando se olha para essa regra é normal, mas iremos perceber que é algo extremamente simples.

A ideia principal é: Negue todo o possível em seu método antes. Dessa forma assumimos retornos antecipados e definimos um fluxo de trabalho padrão.

 

Antes:

Depois:

 

Por mais difícil que seja, nós sempre teremos uma maneira de evitar if-else que não são divertidos de ver e analisar. Em alguns outros casos mais complexos, você pode também aplicar algumas práticas como State ou Strategy Design Patterns, que irão te auxiliar com o fluxo de estado usando a composição de objetos.

Porém, falaremos dessas duas estratégias depois.

Terceira regra: Envolva seus tipos primitivos

Essa regra na realidade é uma das mais simples, pois ela diz que você deve encapsular todos os tipos primitivos dentro dos objetos, prevenindo assim Primitive Obsession Anti-Pattern.

Um int por conta própria, é um tipo sem significado. Quando se tem um método que um de seus parâmetros é um int, o nome do método precisa fazer todo o trabalho para expressar a intenção, ou então, o programador tem que perder um certo tempo tentando entender o intuito.

Suponhamos que o método requer um parâmetro do tipo Hora. Será muito mais fácil saber o comportamento desse parâmetro e do método.

Seguindo essa ideia, um pequeno objeto como esse pode tornar sua aplicação muito mais sustentável, uma vez que, nesse caso, não seria possível passar Ano como parâmetro em um lugar que deveria receber Hora.

 

Antes:

Depois:

Quarta regra: Envolva suas collections em classes

A ideia inicial dessa regra diz que se você tiver um conjunto de elementos e quiser manipulá-los, é necessário criar uma classe dedicada (collection) apenas para este conjunto. Assim, ao atualizar aquele valor, com certeza será em sua collection.

Seguindo o comportamento dessa regra, você deixa os comportamentos relacionados.

O maior objetivo dessa regra é: Aderir o Single Responsibility Principle (A letra S do S.O.L.I.D.) e High Cohesion.

Quinta regra: Use apenas um ponto por linha

Esse “ponto” é o que você usa para chamar métodos em Java ou C#; no caso do PHP seria uma seta.

Esta regra é o exemplo da Lei de Deméter: você nunca deve usar mais de um operador de objeto, ou seja, você não deve encadear chamadas de métodos.

Porém, existe uma exceção. Ela não se aplica a Fluent Interfaces e a qualquer coisa que se implemente o Chaining Pattern (muito usado por exemplo em Query Builders).

Sexta regra: Não abrevie

São incontáveis as vezes em que nós abrimos um código e encontramos uma variável $i.

Por mais comum que seja encontrarmos essa variável em vários projetos em funções de iterações, imagine entender o que seria a variável $n ou $x.

E por mais tentador que seja abreviarmos nomes de variáveis, classes ou métodos, lute contra essa tentação! As abreviações podem ser confusas e tendem a esconder problemas maiores.

Analisar o motivo de estar abreviando é uma ótima solução. Será que isso pode estar acontecendo por estar digitando a mesma palavra várias vezes? Se for verdade, talvez você deva reanalisar seu código para remover duplicações.

Outro caso recorrente é quando os nomes dos seus métodos ou variáveis estão ficando longos; isso pode ser um sinal de que sua classe esteja fazendo coisas que não pertencem a ela.

Dica importante: Sempre tente manter nome de suas classes, métodos ou variáveis, com apenas duas palavras, e que essas palavras não sejam repetitivas.

Considere uma classe com o nome Profile. Um método dessa classe não tem nenhuma necessidade de se chamar createProfile. Basta chamá-lo de create, pois podemos invocá-lo com profile->create(), mantendo uma representação clara do que será realizado.

Sétima regra: Mantenha todas as classes pequenas

Tenha em mente que é recomendável que uma classe tenha no máximo 50 linhas, e que os pacotes não tenham mais do que 10 arquivos. Geralmente,quando criamos uma classe com mais de 50 linhas, atribuímos à ela mais responsabilidades, tornando-as mais difíceis de se entender e também de se reutilizar.

Classes e pacotes devem ser coesos e ter um propósito, e esse propósito deve ser fácil de se entender.

Oitava regra: Não tenha mais que duas variáveis de instância em sua classe

Essa é uma regra na qual, por ser muito simples, não precisaremos de um exemplo. No entanto, é uma das mais difíceis a serem implementadas, já que ela depende de um mindset totalmente diferente do habitual.

Ao termos no máximo duas variáveis de instância, isso irá garantir que estejamos respeitando novamente o Single Responsibility Principle e High Cohesion. Se sua classe tem mais que duas variáveis de instância, bem provável que ela esteja fazendo mais de uma responsabilidade.

Nona regra: Não use Getters ou Setters

No primeiro momento pode parecer uma regra bem estranha, no entanto, a ideia é bem básica. Você retira os getters e setters para poder adicionar decisões no próprio objeto. Qualquer decisão baseada inteiramente no estado de um objeto deve ser feita diretamente nele.

São muitos os benefícios quando aplicamos essa ideia. Reduzimos a duplicação de regras e damos uma melhor compreensão àquele objeto.

Também enriquecemos nosso objeto com lógica e métodos mais valiosos e significativos, não apenas o usando como uma classe com apenas dados.

 

Antes:

Depois:

Bônus: Não comente seus códigos

Essa não é uma regra do Object Calisthenics, e talvez seja mais polêmica até que a regra do else.

Há um tempo atrás, li um post no Medium com o seguinte título: Nunca mais comente seu código.

Achei extremamente polêmico, porém, no decorrer da leitura, percebi que aquilo era fundamental. Recomendo a leitura completa do post.

Irei simplificar o que o autor transmite no artigo: Os métodos muitas vezes fazem mais coisas do que o necessário, e isso torna o código ilegível. Ao quebrar um método em vários outros métodos, removemos a necessidade de escrever comentários, pois isso se tornaria redundante, já que o nosso método faz exatamente o que seu nome diz.

 

Antes:

Depois:

Conclusão

Algumas dessas regras são extremamente simples, porém, implementá-las no seu dia a dia pode se tornar algo complexo.

Com certeza será muito difícil você migrar um projeto com um legado da noite para o dia utilizando essas regras, mas aos poucos você conseguirá implementá-las.

A síntese da questão está em querer que seu o código chegue o mais próximo possível da perfeição. Como você acabou de ver, isso não é algo tão fora da realidade; permita-se evoluir como um programador.

Um ótimo programador não é alguém que sabe 1000 linguagens, mas sim aquele que consegue escrever um código perfeito e coeso.

Muito em breve falaremos de S.O.L.I.D. e outros Design Patterns bem conhecidos.

 

Leave A Comment



Quer receber mais conteúdos brilhantes?