Aposentando o termo “DTO” do nome das suas classes, variáveis e métodos

Photo by Chris Ried on Unsplash

Todo desenvolvedor Java que se preze, em algum momento da sua vida de programador, já criou alguma classe com o sufixo “DTO”. Normalmente estas situações incluem o transporte de informações de um ponto a outro. Nada mais justo, afinal o significado de DTO é Data Transfer Object.

Porém, existem vários contras no simples uso do sufixo DTO no nome de uma classe.

A primeira é que o sufixo “DTO” diz muito pouco sobre a responsabilidade da classe.

Por exemplo, digamos que temos um PedidoDTO usado para guardar informações de pedido. Até aqui, tudo bem. Mas o nome da classe não diz muito sobre o destino ou origem destas informações, o que levanta várias questões:

• Este DTO é usado para exibir informações em uma API?
• Este DTO é usado para receber informações em uma API?
• Este DTO é usado como uma mensagem entre micro serviços?
• Este DTO é usado para guardar informações de pedido em algum cache?
• Etc.

Vemos claramente aqui um espaço para melhoria do nome desta classe, e de uma maneira bem simples. Respectivamente, veja como podemos usar um nome diferente para cada cenário apresentado anteriormente: PedidoResponse, PedidoRequest, PedidoMessage e PedidoCache.

O segundo contra é o sufixo em si. Digamos que você não quer abrir mão do termo DTO, mas ainda assim há mais um porém ao usá-lo. Normalmente o uso de siglas em maiúsculo no meio de variáveis, métodos ou nomes de classes traz uma certa confusão na leitura do código. Podemos citar, além do DTO, as seguintes siglas: CPF, CNPJ, NFE, etc.

Veja o seguinte exemplo de trecho de código para entender esta confusão:

Pessoa pessoa = converterDTOParaEntidade(pessoaDTOOrigem); 

No código acima, temos dois pontos que dão um nó na cabeça ao lê-lo, são eles: DTOParae DTOOrigem. Como temos 2 letras maiúsculas juntas que não fazem parte da mesma palavra ou termo, você acaba não distinguindo imediatamente o termo DTO do código acima, mas sim DTOP ou DTOO, o que não faz sentido.

Sendo assim, ficaria mais legível se usássemos:

Pessoa pessoa = converterDtoParaEntidade(pessoaDtoOrigem);

Como já estamos acostumados no CamelCase a ler cada palavra que começa com maiúsculo como se fosse uma palavra diferente, é mais fácil ler o código acima do que o código anterior. Usei o DTO como exemplo, mas como disse anteriormente, este problema é compartilhado com qualquer situação onde temos uma sigla que é representada por letras maiúsculas.

Embora o uso do “Dto” possa ser justificado em alguns casos, é bem provável que na maioria deles você conseguirá encontrar um termo melhor para substituir este sufixo, dando mais significado para a responsabilidade daquela classe e trazendo mais clareza na leitura do código.