Когда на самом деле желательны / необходимы подписки на события с сильными ссылками?

Question

Я начну с описания проблемы, касающейся событий и сильных ссылок.Скопировано из здесь

Часто бывает, что "субъект" (объект с событием) имеет более длительное время жизни, чем "наблюдатель" (объект, который подписывается насобытие).Когда мы больше не используем наблюдателя, нам бы хотелось, чтобы он собирал мусор;однако, если наблюдатель все еще подписан на событие на субъекте, связанный обработчик события содержит строгую ссылку на наблюдателя, поэтому наблюдатель не будет собирать мусор, пока субъект также не станет мусором или пока наблюдатель не откажется от подписки.

Столкнувшись с этой проблемой, я пошел искать решения.Я прочитал статью Слабые шаблоны событий из MSDN и несколько раз использовал этот шаблон.Это чувствовало себя раздутым.Я искал что-то лучшее и наткнулся на эти две записи в блоге:

• Подписка на события с использованием слабых ссылок
• Решение проблемы с событиями: слабые обработчики событий

Это делает вещи намного проще.Итак, теперь, когда у меня есть простой способ использовать слабые подписки на события, я начинаю задумываться, когда мне следует использовать слабое событие?Оказывается, я не могу придумать причину , а не , чтобы использовать слабые события.

Мой вопрос таков: когда бы вы захотели , чтобы субъект держал сильную ссылку наслушатель?В каком дизайне было бы логично / желательно, чтобы субъект был единственным, кто поддерживал жизнь слушателя.Если слушатель выполняет определенные задачи в вашем приложении, не всегда ли существует «нормальная» ссылка на него?

Я смотрю на это через очки WPF и особенно заинтересован в WPFиспользует сильные ссылки.Но ответы, не относящиеся к WPF, также приветствуются, хотя бы только для того, чтобы быть в курсе этих применений.

Answer 1

public class MyForm : Form
{
    public MyForm()
    {
        this.Closed += delegate
        {
            MessageBox.Show("If events were weak by default, you might never see this message.");
        };
    }
}

Было бы неплохо, если бы шаблон слабого события был более неотъемлемой частью .NET, однако.

Answer 2

Это не ответ на вопрос. Это просто попытка заставить вас прекратить избивать именно эту мертвую лошадь.

Почему CLR не поддерживает слабые события?

А) На них нет достаточного спроса. Я не верю, что это правда. Посмотрите на уродливое раздувание, добавленное WPF для их поддержки.

B) WPF содержит ужасный раздув для поддержки слабых событий. Если кто-то мог оказать давление на команду CLR, чтобы наконец-то обеспечить поддержку CLR для слабых событий, не думаете ли вы, что команда WPF могла бы это сделать?

Поэтому: мы никогда не увидим поддержку CLR для слабых событий.