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:
Top comments (0)