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.