Problema da sobrecarga:

• A sobrecarga de métodos, como no exemplo do programa CollectionClassifier, pode levar a comportamentos inesperados, pois a seleção de qual método invocar ocorre em tempo de compilação, com base no tipo do parâmetro, e não em tempo de execução.

Sobrecarga vs Sobrescrita:

• Enquanto a sobrecarga escolhe o método em tempo de compilação, a sobrescrita escolhe o método correto com base no tipo em tempo de execução, o que torna o comportamento mais previsível.

Evite sobrecargas confusas:

• A sobrecarga pode confundir os programadores quando não está claro qual método será invocado para um conjunto de parâmetros. Isso é especialmente problemático em APIs públicas.

Recomendações:

• Evite exportar duas sobrecargas com o mesmo número de parâmetros.
• Nomeie métodos de forma diferente ao invés de sobrecarregar (como writeInt e writeBoolean).
• Ao usar varargs, evite a sobrecarga.

Caso dos genéricos e autoboxing:

• A introdução de genéricos e autoboxing no Java gerou problemas de sobrecarga, como mostrado no exemplo de List.remove, que pode se comportar de maneira confusa devido à presença de várias sobrecargas.

Interfaces funcionais e lambdas:

• A adição de lambdas no Java 8 aumentou o risco de confusão ao sobrecarregar métodos que recebem interfaces funcionais, principalmente quando essas interfaces não são "radicalmente diferentes".

Soluções práticas:

• Testes explícitos com instanceof podem evitar os problemas associados à sobrecarga.
• As sobrecargas com parâmetros radicalmente diferentes (tipos que não podem ser convertidos entre si) evitam confusões.
• Construtores e sobrecargas: Embora os construtores sejam sempre sobrecarregados, o uso de static factories pode evitar parte dessa complexidade.

Exceções justificadas:

• Em alguns casos, como na adaptação de classes antigas, a sobrecarga pode ser necessária, mas deve ser usada com cuidado, garantindo que os métodos sobrecarregados se comportem de forma idêntica quando invocados com os mesmos parâmetros.

Conclusão:

• Sobrecargas devem ser usadas com parcimônia. Embora tecnicamente possível, muitas vezes é preferível nomear métodos de maneira diferente ou evitar sobrecargas confusas para garantir código mais claro e previsível.

Exemplos do livro: