Я полностью понимаю, что то, что я предлагаю, не соответствует рекомендациям .NET, и, следовательно, вероятно, является плохой идеей только по этой причине. Однако я хотел бы рассмотреть это с двух возможных точек зрения:
(1) Должен ли я рассмотреть возможность использования этого для моей собственной разработки, которая составляет 100% для внутренних целей.
(2) Является ли это концепцией, которую разработчики фреймворка могли бы рассмотреть, чтобы изменить или обновить?
Я думаю об использовании сигнатуры события, которая использует строго типизированный «отправитель», вместо того, чтобы вводить его как «объект», который является текущим шаблоном проектирования .NET. То есть вместо использования стандартной сигнатуры события, которая выглядит следующим образом:
class Publisher
{
public event EventHandler<PublisherEventArgs> SomeEvent;
}
Я рассматриваю возможность использования подписи события, которая использует строгое типизированный параметр «отправитель», следующим образом:
Сначала определите «StrongTypedEventHandler»:
[SerializableAttribute]
public delegate void StrongTypedEventHandler<TSender, TEventArgs>(
TSender sender,
TEventArgs e
)
where TEventArgs : EventArgs;
Это не сильно отличается от действия , но, используя StrongTypedEventHandler, мы обеспечиваем, чтобы TEventArgs был получен из System.EventArgs.
Далее, в качестве примера, мы можем использовать StrongTypedEventHandler в классе публикации следующим образом:
class Publisher
{
public event StrongTypedEventHandler<Publisher, PublisherEventArgs> SomeEvent;
protected void OnSomeEvent()
{
if (SomeEvent != null)
{
SomeEvent(this, new PublisherEventArgs(...));
}
}
}
Приведенная выше схема позволит подписчикам использовать обработчик событий со строгим типом, который не требует приведения:
class Subscriber
{
void SomeEventHandler(Publisher sender, PublisherEventArgs e)
{
if (sender.Name == "John Smith")
{
// ...
}
}
}
Я полностью понимаю, что это нарушает стандартный шаблон обработки событий .NET; однако имейте в виду, что в случае контравариантности подписчик может использовать традиционную подпись для обработки событий, если это необходимо:
class Subscriber
{
void SomeEventHandler(object sender, PublisherEventArgs e)
{
if (((Publisher)sender).Name == "John Smith")
{
// ...
}
}
}
То есть, если обработчику событий необходимо подписаться на события из разнородных (или, возможно, неизвестных) типов объектов, обработчик может ввести параметр «отправитель» как «объект», чтобы обработать всю ширину потенциальных объектов отправителя.
Кроме нарушения соглашения (это то, что я не воспринимаю легко, поверьте мне), я не могу думать о каких-либо недостатках этого.
Здесь могут быть некоторые проблемы с соответствием CLS. Это действительно работает в Visual Basic .NET 2008 на 100% (я проверял), но я считаю, что более старые версии Visual Basic .NET до 2005 года не имеют ковариации и контравариантности делегатов. [Редактировать: С тех пор я проверил это, и это подтверждается: VB.NET 2005 и ниже не может справиться с этим, но VB.NET 2008 в порядке на 100%. См. «Редактирование # 2» ниже.] Могут быть и другие языки .NET, в которых также есть проблема, я не уверен.
Но я не вижу себя разработчиком для какого-либо языка, кроме C # или Visual Basic .NET, и я не против ограничить его C # и VB.NET для .NET Framework 3.0 и выше. (Если честно, я не мог представить, что вернусь к 2.0.)
Может кто-нибудь еще подумать о проблеме с этим? Или это просто настолько нарушает конвенцию, что заставляет людей болеть?
Вот некоторые ссылки, которые я нашел:
(1) Руководство по разработке событий [MSDN 3.5]
(2) C # simple Event Raising - использование «отправителя» и пользовательских EventArgs [StackOverflow 2009]
(3) Шаблон подписи события в .net [StackOverflow 2008]
Меня интересует мнение всех и каждого по этому поводу ...
Заранее спасибо,
Mike
Редактировать # 1: Это ответ на сообщение Томми Карлира :
Вот полный рабочий пример, который показывает, что с этим подходом могут сосуществовать как обработчики событий со строгой типизацией, так и текущие стандартные обработчики событий, которые используют параметр 'object sender' Вы можете скопировать и вставить код и запустить его:
namespace csScrap.GenericEventHandling
{
class PublisherEventArgs : EventArgs
{
// ...
}
[SerializableAttribute]
public delegate void StrongTypedEventHandler<TSender, TEventArgs>(
TSender sender,
TEventArgs e
)
where TEventArgs : EventArgs;
class Publisher
{
public event StrongTypedEventHandler<Publisher, PublisherEventArgs> SomeEvent;
public void OnSomeEvent()
{
if (SomeEvent != null)
{
SomeEvent(this, new PublisherEventArgs());
}
}
}
class StrongTypedSubscriber
{
public void SomeEventHandler(Publisher sender, PublisherEventArgs e)
{
MessageBox.Show("StrongTypedSubscriber.SomeEventHandler called.");
}
}
class TraditionalSubscriber
{
public void SomeEventHandler(object sender, PublisherEventArgs e)
{
MessageBox.Show("TraditionalSubscriber.SomeEventHandler called.");
}
}
class Tester
{
public static void Main()
{
Publisher publisher = new Publisher();
StrongTypedSubscriber strongTypedSubscriber = new StrongTypedSubscriber();
TraditionalSubscriber traditionalSubscriber = new TraditionalSubscriber();
publisher.SomeEvent += strongTypedSubscriber.SomeEventHandler;
publisher.SomeEvent += traditionalSubscriber.SomeEventHandler;
publisher.OnSomeEvent();
}
}
}
Edit # 2: Это ответ на заявление Эндрю Хэра относительно ковариации и контравариантности и того, как оно применяется здесь. Делегаты на языке C # так долго имели ковариацию и контравариантность, что это кажется «внутренним», но это не так. Это может быть даже то, что включено в CLR, я не знаю, но Visual Basic .NET не получал возможности ковариации и контравариантности для своих делегатов до .NET Framework 3.0 (VB.NET 2008). В результате Visual Basic.NET для .NET 2.0 и ниже не сможет использовать этот подход.
Например, приведенный выше пример можно перевести на VB.NET следующим образом:
Namespace GenericEventHandling
Class PublisherEventArgs
Inherits EventArgs
' ...
' ...
End Class
<SerializableAttribute()> _
Public Delegate Sub StrongTypedEventHandler(Of TSender, TEventArgs As EventArgs) _
(ByVal sender As TSender, ByVal e As TEventArgs)
Class Publisher
Public Event SomeEvent As StrongTypedEventHandler(Of Publisher, PublisherEventArgs)
Public Sub OnSomeEvent()
RaiseEvent SomeEvent(Me, New PublisherEventArgs)
End Sub
End Class
Class StrongTypedSubscriber
Public Sub SomeEventHandler(ByVal sender As Publisher, ByVal e As PublisherEventArgs)
MessageBox.Show("StrongTypedSubscriber.SomeEventHandler called.")
End Sub
End Class
Class TraditionalSubscriber
Public Sub SomeEventHandler(ByVal sender As Object, ByVal e As PublisherEventArgs)
MessageBox.Show("TraditionalSubscriber.SomeEventHandler called.")
End Sub
End Class
Class Tester
Public Shared Sub Main()
Dim publisher As Publisher = New Publisher
Dim strongTypedSubscriber As StrongTypedSubscriber = New StrongTypedSubscriber
Dim traditionalSubscriber As TraditionalSubscriber = New TraditionalSubscriber
AddHandler publisher.SomeEvent, AddressOf strongTypedSubscriber.SomeEventHandler
AddHandler publisher.SomeEvent, AddressOf traditionalSubscriber.SomeEventHandler
publisher.OnSomeEvent()
End Sub
End Class
End Namespace
VB.NET 2008 может работать на 100% нормально. Но сейчас я проверил его на VB.NET 2005, просто чтобы убедиться, и он не компилируется, заявив:
Метод 'Public Sub
SomeEventHandler (отправитель как объект, e
Как
vbGenericEventHandling.GenericEventHandling.PublisherEventArgs)»
не имеет той же подписи, что и
делегат 'Делегат Sub
StrongTypedEventHandler (Of TSender,
TEventArgs As System.EventArgs) (отправитель
As Publisher, e As
PublisherEventArgs) '
По сути, делегаты инвариантны в версиях VB.NET 2005 и ниже. Я на самом деле думал об этой идее пару лет назад, но неспособность VB.NET справиться с этим беспокоила меня ... Но я теперь твердо перешел на C #, и VB.NET теперь может справиться с этим, так что, ну, следовательно, этот пост.
Редактировать: Обновление № 3
Хорошо, я уже довольно успешно использую это. Это действительно хорошая система. Я решил назвать мой «StrongTypedEventHandler» как «GenericEventHandler», определенный следующим образом:
[SerializableAttribute]
public delegate void GenericEventHandler<TSender, TEventArgs>(
TSender sender,
TEventArgs e
)
where TEventArgs : EventArgs;
Кроме этого переименования, я реализовал его в точности так, как описано выше.
Это срабатывает по правилу FxCop CA1009, которое гласит:
"По соглашению, события .NET имеют два
параметры, которые определяют событие
данные отправителя и события. Обработчик события
подписи должны следовать этой форме:
void MyEventHandler (отправитель объекта,
EventArgs e). Параметр «отправитель»
всегда имеет тип System.Object, даже
если можно нанять больше
конкретный тип. Параметр «е»
всегда типа System.EventArgs.
События, которые не предоставляют данные о событиях
следует использовать System.EventHandler
тип делегата. Возвращаются обработчики событий
недействительными, чтобы они могли отправлять каждое событие
к нескольким целевым методам. Любое значение
возвращенный целью будет потерян
после первого звонка. "
Конечно, мы все это знаем и все равно нарушаем правила. (Все обработчики событий могут использовать стандартный «объект-отправитель» в своей подписи, если они предпочтительнее, в любом случае - это непрерывное изменение.)
Так что использование SuppressMessageAttribute делает свое дело:
[SuppressMessage("Microsoft.Design", "CA1009:DeclareEventHandlersCorrectly",
Justification = "Using strong-typed GenericEventHandler<TSender, TEventArgs> event handler pattern.")]
Я надеюсь, что этот подход станет стандартом в какой-то момент в будущем. Это действительно работает очень хорошо.
Спасибо за ваше мнение, ребята, я действительно ценю это ...
Mike