Какую цель действительно выполняют защищенные или частные (нестатические) события в .NET?
Кажется, что любое частное или защищенное событие легче обрабатывается с помощью виртуального метода. Я могу (несколько) видеть необходимость этого в статических событиях, но не для обычных событий.
Есть ли у вас прецедент, прежде чем это ясно продемонстрирует необходимость или преимущество для нестатического защищенного или частного события?
Мне кажется, что хорошим примером того, где частное событие полезно, является компонентное/контрольное здание, часто у вас может быть компонент, состоящий из 1 или более других компонентов, частные события, в которых содержатся компоненты, могут подписаться на удобная и простая реализация шаблона наблюдателя.
Edit:
Позвольте мне привести пример...
Предположим, вы пишете элемент управления Grid, и внутри этого элемента управления вы, скорее всего, будете иметь кучу содержащихся классов, которые создаются динамически, например, Rows, Cols, headers и т.д., например, вы хотите уведомить эти содержащиеся классы о том, что что-то они заботятся о том, что произошло, скажем, изменение Skinning или что-то в этом роде, то, что вам не обязательно нужно показывать в качестве события пользователям сетки, здесь частные приложения удобны, просто есть один или два обработчика и как вы создайте каждый экземпляр своей строки или столбца или любого другого, связанного с обработчиком, так как иначе вам просто нужно написать собственный механизм наблюдателя, а не сложно, но почему, когда вам это не нужно, и вы можете просто использовать события многоадресной рассылки.
Здесь немного странный, но реальный сценарий, который я реализовал один раз. У вас есть генерируемые машиной и созданные пользователем половинки частичного класса. Полученная машиной половина содержит код, который хочет сообщить генерируемую пользователем половину при возникновении какого-либо события. Но половина, созданная пользователями, может ничего не делать, или, возможно, это будет сделано довольно много. Кажется грубым порожденной машиной половиной требовать, чтобы генерируемая пользователем половина реализовала конкретный метод для обработки сообщения, которое они не интересуют при прослушивании.
Чтобы решить эту проблему, генерируемая машиной половина может запускаться на частном событии. Если пользовательская половина заботится, он может подписаться на событие. Если нет, он может игнорировать его.
Этот сценарий теперь более элегантно рассмотрен частичными методами в С# 3, но это не было вариантом в тот же день.
Вложенные типы имеют доступ к закрытым и защищенным событиям. Я использовал эту функцию для уведомления дочерних элементов управления (вложенного типа) изменений состояния в родительском элементе управления (охватывающий тип) в приложении Silverlight.
Извините, что перетащил старый поток, но я использую частные события с безнаказанностью в одном из своих проектов, и лично я считаю это хорошим способом решения проблемы с дизайном:
Вот сокращенный код:
public class MyClass
{
private event EventHandler _myEvent;
public ExternalObject { get; set; }
public event EventHandler MyEvent
{
add
{
if (_myEvent.GetInvocationList().Length == 0 && value != null)
ExternalObject.ExternalEvent += HandleEvent;
_myEvent+= value;
}
remove
{
_myEvent-= value;
if (_myEvent.GetInvocationList().Length == 0)
ExternalObject.ExternalEvent -= HandleEvent;
}
}
private void HandleEvent(object sender, EventArgs e)
{
_myEvent.Raise(this, EventArgs.Empty); // raises the event.
}
}
В принципе, MyEvent только когда-либо поднимается в обработчике событий ExternalObject.ExternalEvent, поэтому, если нет обработчиков для MyEvent, тогда мне не нужно прикреплять обработчик к внешнему событию, слегка увеличивая код путем сохранения фрейма стека.
Не только текущий экземпляр может получить доступ к частному члену. Другие экземпляры того же типа тоже могут! Это позволяет использовать некоторые сценарии, в которых это управление доступом может быть полезно.
Я думаю о древовидной структуре, где все узлы наследуют определенный тип, а частное/защищенное событие позволяет распространять листовые события родителям. Поскольку они являются одним и тем же типом, родитель может зарегистрироваться на дочернее частное событие. Однако любой клиент древовидной структуры не может.
Я могу определенно увидеть пример использования в каталоге, таком как система хранения, где каждый каталог должен распространять свою последнюю измененную дату на родителя, например.