Primitive Obsession

Olá, tudo bem? Quem nunca viu (ou escreveu) aquele método com tantos parâmetros do tipo string, int, boolean  que precisou até quebrar linha para conseguir ver? Bem, hoje vamos falar um pouco sobre este problema e explicar o porque é um problema.

Por que é um Anti-pattern?

Primitive obsession é classificado como um um anti padrão por dois principais motivos. Veja o exemplo:

Ex: 1.0


public class EnvioDeEmail{

public void Enviar(string email, string apresentacao, string mensagem, int genero){

/*implementacao*/

}

}

Um código simples, certo? Bem, pode até parecer, mas não é.

Perceba que, o método “Enviar”, espera quatro(4) parâmetros: um email, uma apresentação e uma mensagem do tipo string e o gênero do tipo int. Vamos analisar o parâmetro email:

Todo e-mail, para ser válido, precisa ter obrigatoriamente uma das seguintes estruturas:

  • <nome escolhido pelo usuario>@dominio.com
  • <nome escolhido pelo usuario>@dominio.com
  • <nome escolhido pelo usuario>@dominio.org
  • <nome escolhido pelo usuario>@dominio.gov
  • <nome escolhido pelo usuario>@dominio.edu

Concluímos então que um e-mail possui algumas Invariantes para garantir que ele esteja correto, sendo assim, ao definirmos o parâmetro email como string, não estamos deixando claro como essa string realmente tem que ser, ou seja, a assinatura deste método é desonesta, não expressa realmente o que é um e-mail. Ter um método desonesto é o primeiro motivo da obsessão por tipos primitivos ser um Anti-pattern.

Ainda analisando o exemplo 1.0, imagine que você possua implementações diferentes de envio de e-mail e, para cada implementação, você precise realizar as mesmas validações para garantir que a string email seja um email válido.

O parâmetro “apresentacao” define qual o pronome de tratamento que utilizaremos, com base no tipo do gênero. Precisaremos inserir essa lógica para cada implementação também.

Todas essas validações irão se repetir para cada implementação de envio de e-mail que você possuir. Sendo assim, conseguimos perceber que, essa repetição de código, viola o principio DRY (Don’t Repeat yourself), dificultando a reutilização e manutenção do código. A violação deste principio é o segundo motivo que faz a obsessão por tipos primitivos ser um Anti-pattern.

Evitando o Anti-pattern

Ao invés de utilizarmos os tipos primitivos, poderíamos ter uma classe “Email” que encapsularia todas as invariantes de validação, garantindo sempre um e-mail válido. Poderíamos também ter uma classe “CorpoDoEmail” que encapsularia a “apresentação” e a “mensagem”, definindo internamente qual o pronome de tratamento,  criando a mensagem do e-mail.

Essas refatorações tornaria o nosso código reutilizável e de fácil manutenção, pois não precisaríamos sair alterando em vários lugares a mesma coisa. Teríamos um código honesto, que expressa exatamente o que precisa e o que irá realizar.

Também teríamos um código mais expressivo, facilitando a identificação de conceitos do domínio, que nos permite identificar de forma mais clara onde determinadas validações devem estar e quais suas invariantes ( ajudando a garantir outro principio, o SRP).

Conclusão

Discutimos aqui os principais problemas que o uso excessivo de tipos primitivos podem trazer para o nosso software.

Identificamos que a obsessão por tipos primitivos dificulta a reutilização de código e esconde possíveis validações de negocio, além  de entendemos a importância de um código expressivo.

É isso. Espero que tenha gostado. Aguardo seu feedback nos comentários 🙂

Abraços.

Referencias

Clean code

pluralsight

 

 

 

 

 

 

Anúncios

Deixe um comentário

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