Y a-t-il une situation où il serait préférable d'utiliser des références faibles au lieu d'une simple composition?

Bien que les documents Java spécifient que les références faibles sont principalement destinées à canoniser les mappages, vous trouverez beaucoup , beaucoup , beaucoup de gens sur Internet déclarant que le WeakHashMap est parfait pour stocker des métadonnées d'objet pendant sa durée de vie. Cependant, personne ne se soucie de faire un exemple compréhensible ET approprié .

Utiliser WeakHashMap pour ajouter un objet à certaines propriétés ou stocker des sons de métadonnées pour moi, comme une décision arbitraire basée sur la volonté d'utiliser simplement la fichue chose. En d'autres termes - une mauvaise conception . Je comprends qu'il y a des situations où l'héritage peut ne pas être disponible (classes finales, interfaces), mais qu'en est-il de la composition? Je ne peux pas penser à un exemple où la composition ne serait pas une option. Et certainement un meilleur, car il repose sur un principe bien établi, au lieu d'une "bizarrerie de la langue".

Alors, y a-t-il une situation où il serait préférable d'utiliser des références faibles au lieu d'une simple composition? Sinon, pourquoi tout le monde sur Internet semble-t-il se tromper?

Disons que je dois associer certaines métadonnées à certains objets de données. Il s'agit d'un scénario assez courant. Je ne contrôle pas les objets de données, et il y en a beaucoup, et l'API en question (rappels, méthodes virtuelles, etc.) me propose ces objets de données, mais sans mes métadonnées. Donc, je dois suivre un état pour chacun de ces objets de données, à savoir ceux que j'ai vus auparavant et que je pourrais revoir. J'appellerai ces métadonnées un ornement, qui est un terme parfois utilisé pour ce concept.

La composition simple permet une recherche facile de l'objet ornant (celui avec des métadonnées) à l'autre objet (celui avec des données), avec la présomption que puisque je contrôle la conception de l'objet de métadonnées, je peux y mettre une référence directement à l'objet de données .

Cependant, à moins que vous ne contrôliez la conception de l'objet de données et que vous ne puissiez le modifier, la composition simple ne fournit pas la recherche inversée (de l'objet de données à certaines métadonnées). En fait, à moins que vous ne disposiez d'une collection d'objets de métadonnées, vous ne pouvez même pas localiser l'élément de métadonnées associé en fonction d'un élément d'objet (données).

En plus du problème de recherche dans la direction allant de l'objet pour trouver ses métadonnées décoratives, il y a aussi le problème de la durée de vie des métadonnées.

Les métadonnées qui s'accumulent et ne sont jamais publiées, même lorsque l'objet de données n'est plus utilisé, constituent une fuite de mémoire.

Une table de hachage de référencement faible résout les deux problèmes. Il permet de localiser les métadonnées en fonction des données et permet de libérer les métadonnées à un moment donné après la libération des données.

Notez en outre qu'un hashmap de référencement faible permet non seulement aux valeurs (métadonnées) d'être récupérées (gc'ed), mais également aux clés (de données) d'être récupérées (gc'ed), car si les clés étaient conservées, ce serait également un fuite de mémoire, et en outre, les valeurs n'ont jamais pu être publiées non plus.