Чи існує ситуація, коли краще використовувати слабкі посилання замість простого складу?

Хоча документи Java вказують, що слабкі посилання в основному стосуються канонізації відображень, в Інтернеті ви знайдете багатьох , багатьох , багатьох людей, які стверджують, що WeakHashMap ідеально підходить для зберігання метаданих об’єктів протягом свого життя. Однак ніхто не заважає зробити зрозумілий І відповідний приклад.

Використання WeakHashMap для додавання об'єкту якихось властивостей або збереження звуків метаданих для мене, як довільне рішення, засноване на волі просто використовувати прокляту річ. Іншими словами - погана конструкція . Я розумію, що існують ситуації, коли успадкування може бути недоступним (підсумкові класи, інтерфейси), але як бути зі складом? Я не можу придумати жодного прикладу, коли композиція не була б варіантом. І, звичайно, кращий, тому що він спирається на усталений принцип, а не на "мовну вигадку".

Отже, чи існує ситуація, коли було б краще використовувати слабкі посилання замість простого складу? Якщо ні, то чому всі в Інтернеті, здається, помиляються?

Скажімо, мені потрібно пов’язати деякі метадані з деякими об’єктами даних. Це досить поширений сценарій. Я не контролюю об'єкти даних, і їх дуже багато, і відповідний API (зворотні виклики, віртуальні методи тощо) пропонує мені ці об’єкти даних, але без моїх метаданих. Отже, мені потрібно відслідковувати деякий стан кожного з цих об'єктів даних, а саме тих, які я бачив раніше і які можуть бачити знову. Я називатиму ці метадані прикрасою, що іноді використовується для цього поняття.

Проста композиція забезпечує легкий пошук від об'єкта, що прикрашає (того, який має метадані), до іншого об'єкта (того, що має дані), з припущенням, що оскільки я керую дизайном об'єкта метаданих, я можу помістити в ньому посилання безпосередньо на об'єкт даних .

Однак, якщо ви не керуєте дизайном об’єкта даних і не зможете його змінити, простий склад не забезпечує зворотного пошуку (від об'єкта даних до деяких метаданих). Насправді, якщо у вас немає колекції об’єктів метаданих, ви навіть не можете знайти пов'язаний елемент метаданих із даним елементом (даними).

Окрім проблеми пошуку в напрямку, що йде від об’єкта, щоб знайти його прикрашаючі метадані, існує також проблема життя метаданих.

Метадані, які накопичуються і ніколи не вивільняються, навіть коли об'єкт даних більше не використовується, є витоком пам'яті.

Слабка хешмак, що посилається, вирішує обидві проблеми. Це дозволяє розташовувати метадані за даними і дозволяє звільняти метадані через деякий час після звільнення даних.

Далі зауважимо, що слабке посилання на хешмак дозволяє відновлювати не тільки (метадані) значення (gc'ed), а й ключі (data), які потрібно відшкодувати (gc'ed), оскільки якби ключі зберігалися, це також було б витоку пам'яті, і далі, значення також ніколи не можна було випустити.