Sobrescreva sempre o toString
Esta é uma série baseada no entendimento de tópicos relacionados ao livro com foco no resumo.
Contextualizando
O método toString é um dos métodos que são herdados da classe Objetc.
A implementação desse método na classe Object é a seguinte :
public String toString() {
return getClass().getName() + "@" + Integer.toHexString(hashCode());
}
Que é o nome da classe seguido de @ e do valor hexadecimal sem sinal do hashcode.
O porquê
Porque temos que nos preocupar? Pense bem, se formos utilizar a implementação padrão que imprime o objeto algo como :
br.com.conta.Usuario@c712a7ee
O quanto visualizar esse trecho em seu log pode ajudar a realizar debug do seu código de maneira eficiente?
Seria bem melhor visualizar os dados que identifiquem de fato o objeto, certo?
Exemplo
@Override
public String toString() {
return "Usuario{" +
"nome='" + nome + '\'' +
", email='" + email + '\'' +
", nascimento=" + nascimento +
'}';
}
Acima sobrescrevemos o toString da classe Usuario por isso ela esta com a anotação @override.
Veja como esta muito mais legível e se logar o objeto iremos receber os dados no seguinte formato:
Usuario{nome='Ana dos Santos', email='anasantos10@gmail.com', nascimento=1977-08-15}
Hum...
- Pode surgir uma dúvida que muitos devs acabam tendo referente a LGPD, pois dependendo do dado que o objeto guarda estado é perigoso registrarmos em logs, para isso é importante que você configure em sua dependência de logs mascaramento de alguns dados de logs, em alguns casos vale apena também verificar se faz sentido ter o dado no toString.
- Não coloque valores que não são acessíveis da classe pois isso não auxiliaria no debug do objeto e faria com que uma informação restrita da classe fique visível.
O lado bom
A maioria das Ides permite que seja sobrescrito o toString de forma mais automática, por exemplo no Intellij temos a opção através do menu direito do mouse > generate > toString e aparece a tela para selecionarmos quais informações são necessárias para gerar o toString.
Nem sempre faz sentido...
Nem sempre os objetos de seu sistema terão objetivo de guardar estado como por exemplo um controller ou um service, neste caso não faz sentido sobrescrever o toString. Geralmente isso só faz sentido para classes de dominío ou que representam objetos de transação e guardem estado.
Outro ponto que deve ser levado em condieração é se uma superclasse já sobrescreveu esse método.
Top comments (0)