Utiliser judicieusement la surcharge

Problème de surcharge :

• La surcharge de méthode, comme dans l'exemple du programme CollectionClassifier, peut conduire à un comportement inattendu, car la sélection de la méthode à appeler se produit au moment de la compilation, en fonction du type de paramètre, et non au moment de l'exécution.

Surcharge vs écrasement :

• Alors que la surcharge choisit la méthode au moment de la compilation, la substitution choisit la méthode correcte en fonction du type au moment de l'exécution, ce qui rend le comportement plus prévisible.

Évitez toute confusion :

• La surcharge peut dérouter les programmeurs lorsqu'il n'est pas clair quelle méthode sera invoquée pour un ensemble de paramètres. Ceci est particulièrement problématique dans les API publiques.

Recommandations :

• Évitez d'exporter deux surcharges avec le même nombre de paramètres.
• Nommez les méthodes différemment au lieu de les surcharger (comme writeInt et writeBoolean).
• Lorsque vous utilisez des varargs, évitez de surcharger.

Cas des génériques et autoboxing :

• L'introduction des génériques et de l'autoboxing en Java a conduit à des problèmes de surcharge, comme le montre l'exemple de List.remove, qui peut se comporter de manière confuse en raison de la présence de plusieurs surcharges.

Interfaces fonctionnelles et lambdas :

• L'ajout de lambdas dans Java 8 a augmenté le risque de confusion en surchargeant les méthodes qui prennent des interfaces fonctionnelles, surtout lorsque ces interfaces ne sont pas « radicalement différentes ».

Solutions pratiques :

• Des tests explicites avec instanceof peuvent éviter les problèmes associés à la surcharge.
• Les surcharges avec des paramètres radicalement différents (types qui ne peuvent pas être convertis entre eux) évitent toute confusion.
• Constructeurs et surcharge : bien que les constructeurs soient toujours surchargés, l'utilisation d'usines statiques peut éviter une partie de cette complexité.

Exceptions justifiées :

• Dans certains cas, comme l'adaptation d'anciennes classes, une surcharge peut être nécessaire, mais elle doit être utilisée avec précaution, en garantissant que les méthodes surchargées se comportent de manière identique lorsqu'elles sont invoquées avec les mêmes paramètres.

Conclusion :

• Les surcharges doivent être utilisées avec parcimonie. Bien que techniquement possible, il est souvent préférable de nommer les méthodes différemment ou d'éviter les surcharges confuses pour garantir un code plus clair et plus prévisible.

Exemples tirés du livre :

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!