Подпись события в .NET - использование строго типизированного «отправителя»?

Я полностью понимаю, что то, что я предлагаю, не соответствует рекомендациям .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;

Это не так уж и отличается от Action <TSender, TEventArgs>, но, используя 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% хорош. См. «Edit # 2» ниже.] Могут быть другие языки .NET, у которых тоже есть проблемы с этим, я не уверен.

Но я не вижу себя разработчиком для какого-либо языка, кроме C # или Visual Basic .NET, и не возражаю ограничить его C # и VB.NET для .NET Framework 3.0 и выше. (Честно говоря, я не мог себе представить, что вернусь к 2.0 в тот момент.)

Кто-нибудь еще может подумать о проблеме с этим? Или это просто настолько противоречит общепринятым нормам, что заставляет людей перевернуться?

Вот несколько ссылок, которые я нашел:

(1) Рекомендации по организации мероприятий [MSDN 3.5]

(2) Простое создание событий C # - использование «отправителя» по сравнению с настраиваемыми EventArgs [StackOverflow 2009]

(3) Шаблон подписи событий в .NET [StackOverflow 2008]

Меня интересует мнение каждого и каждого по этому поводу ...

Заранее спасибо,

Майк

Редактировать # 1: это ответ на сообщение Томми Карлье :

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

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();
        }
    }
}

Изменить № 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 As vbGenericEventHandling.GenericEventHandling.PublisherEventArgs)' не имеет той же подписи, что и делегат 'Delegate Sub StrongTypedEventHandler (Of TSender, TEventArgs As System.EventArgs Publisher) (отправитель как System.EventArgs Publisher) (отправитель As '

По сути, делегаты инвариантны в версиях 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;

Помимо этого переименования, я реализовал его точно так, как описано выше.

Он нарушает правило CA1009 FxCop, которое гласит:

«По соглашению, у событий .NET есть два параметра, которые определяют отправителя события и данные события. Сигнатуры обработчика событий должны иметь следующую форму: void MyEventHandler (отправитель объекта, EventArgs e). Параметр« отправитель »всегда имеет тип System.Object, даже если можно использовать более конкретный тип. Параметр e всегда имеет тип System.EventArgs. События, которые не предоставляют данные о событиях, должны использовать тип делегата System.EventHandler. Обработчики событий возвращают void, чтобы они могли отправлять каждое событие для нескольких целевых методов. Любое значение, возвращаемое целью, будет потеряно после первого вызова ".

Конечно, мы все это знаем и все равно нарушаем правила. (Все обработчики событий могут использовать стандартный «отправитель объекта» в своей подписи, если это необходимо, в любом случае - это неизменное изменение.)

Итак, использование a SuppressMessageAttributeделает свое дело:

[SuppressMessage("Microsoft.Design", "CA1009:DeclareEventHandlersCorrectly",
    Justification = "Using strong-typed GenericEventHandler<TSender, TEventArgs> event handler pattern.")]

Я надеюсь, что в какой-то момент в будущем этот подход станет стандартом. Это действительно очень хорошо работает.

Спасибо за ваше мнение, ребята, я очень ценю это ...

Майк

Кажется, Microsoft подхватила это, поскольку аналогичный пример теперь есть на MSDN:

Общие делегаты

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

Среда выполнения Windows (WinRT) представляет TypedEventHandler<TSender, TResult>делегата, который делает то же самое, что и вы StrongTypedEventHandler<TSender, TResult>, но, очевидно, без ограничения на TResultпараметр типа:

public delegate void TypedEventHandler<TSender, TResult>(TSender sender,
                                                         TResult args);

Документация MSDN находится здесь .

Я не согласен со следующими утверждениями:

• Я считаю, что более старые версии Visual Basic .NET до 2005 года не имеют ковариации делегатов и контравариантности.
• Я прекрасно понимаю, что это граничит с богохульством.

Прежде всего, все, что вы здесь сделали, не имеет ничего общего с ковариацией или контравариантностью. ( Изменить: предыдущее утверждение неверно, для получения дополнительной информации см. Ковариацию и контравариантность в делегатах ) Это решение будет отлично работать во всех версиях CLR 2.0 и выше (очевидно, это не будет работать в приложении CLR 1.0, поскольку оно использует дженерики).

Во-вторых, я категорически не согласен с тем, что ваша идея граничит с «богохульством», поскольку это замечательная идея.

Я взглянул на то, как это было решено с помощью нового WinRT и на основе других мнений здесь, и, наконец, решил сделать это следующим образом:

[Serializable]
public delegate void TypedEventHandler<in TSender, in TEventArgs>(
    TSender sender,
    TEventArgs e
) where TEventArgs : EventArgs;

Это, по-видимому, лучший способ продвижения вперед, учитывая использование имени TypedEventHandler в WinRT.

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

Насколько я понимаю, поле «Отправитель» всегда должно относиться к объекту, который содержит подписку на событие. Если бы у меня были мои druthers, также было бы поле, содержащее информацию, достаточную для отмены подписки на событие, если оно станет необходимым (*) (рассмотрим, например, регистратор изменений, который подписывается на события 'collection-changed'; он состоит из двух частей , одна из которых выполняет фактическую работу и содержит фактические данные, а другая предоставляет оболочку общедоступного интерфейса, основная часть может содержать слабую ссылку на часть оболочки. Если часть оболочки будет собираться сборщиком мусора, это будет означать никто больше не интересовался собираемыми данными, и регистратор изменений, таким образом, должен отказаться от подписки на любое полученное событие).

Поскольку возможно, что объект может отправлять события от имени другого объекта, я вижу некоторую потенциальную полезность наличия поля «отправитель», имеющего тип объекта, и наличия поля, производного от EventArgs, которое содержит ссылку на объект, который должен действовать. Однако бесполезность поля «отправитель», вероятно, ограничена тем фактом, что у объекта нет чистого способа отписаться от неизвестного отправителя.

(*) На самом деле, более простой способ обработки отказа от подписки - иметь тип делегата многоадресной рассылки для функций, возвращающих логическое значение; если функция, вызываемая таким делегатом, возвращает True, делегат будет исправлен для удаления этого объекта. Это означало бы, что делегаты больше не будут по-настоящему неизменными, но должна быть возможность произвести такое изменение поточно-безопасным способом (например, обнуляя ссылку на объект и заставляя код делегата многоадресной рассылки игнорировать любые встроенные ссылки на нулевые объекты). В этом сценарии попытка публикации и событие для удаленного объекта могут быть обработаны очень чисто, независимо от того, откуда пришло событие.

Оглядываясь назад на богохульство как на единственную причину, по которой отправитель является типом объекта (если не учитывать проблемы с контравариантностью в коде VB 2005, что является ошибкой Microsoft, IMHO), может ли кто-нибудь предложить хотя бы теоретический мотив для прибивания второго аргумента к типу EventArgs. Если пойти еще дальше, есть ли веская причина соответствовать рекомендациям и соглашениям Microsoft в данном конкретном случае?

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

[Пример 1]

public delegate void ConnectionEventHandler(Server sender, Connection connection);

public partial class Server
{
    protected virtual void OnClientConnected(Connection connection)
    {
        if (ClientConnected != null) ClientConnected(this, connection);
    }

    public event ConnectionEventHandler ClientConnected;
}

[Пример 2]

public delegate void ConnectionEventHandler(object sender, ConnectionEventArgs e);

public class ConnectionEventArgs : EventArgs
{
    public Connection Connection { get; private set; }

    public ConnectionEventArgs(Connection connection)
    {
        this.Connection = connection;
    }
}

public partial class Server
{
    protected virtual void OnClientConnected(Connection connection)
    {
        if (ClientConnected != null) ClientConnected(this, new ConnectionEventArgs(connection));
    }

    public event ConnectionEventHandler ClientConnected;
}

В текущей ситуации (отправитель - объект) вы можете легко прикрепить метод к нескольким событиям:

button.Click += ClickHandler;
label.Click += ClickHandler;

void ClickHandler(object sender, EventArgs e) { ... }

Если бы отправитель был универсальным, цель события щелчка была бы не типа Button или Label, а типа Control (поскольку событие определено в Control). Таким образом, некоторые события в классе Button будут иметь цель типа Control, а другие - другие типы целей.

Я не думаю, что что-то плохое в том, что ты хочешь делать. По большей части я подозреваю, что этот object senderпараметр остается, чтобы продолжать поддерживать код до 2.0.

Если вы действительно хотите внести это изменение для общедоступного API, вы можете подумать о создании собственного базового класса EvenArgs. Что-то вроде этого:

public class DataEventArgs<TSender, TData> : EventArgs
{
    private readonly TSender sender, TData data;

    public DataEventArgs(TSender sender, TData data)
    {
        this.sender = sender;
        this.data = data;
    }

    public TSender Sender { get { return sender; } }
    public TData Data { get { return data; } }
}

Тогда вы можете объявить свои события вот так

public event EventHandler<DataEventArgs<MyClass, int>> SomeIndexSelected;

И такие методы:

private void HandleSomething(object sender, EventArgs e)

по-прежнему сможет подписаться.

РЕДАКТИРОВАТЬ

Эта последняя строка заставила меня немного задуматься ... Вы действительно должны иметь возможность реализовать то, что вы предлагаете, без нарушения каких-либо внешних функций, поскольку среда выполнения не имеет проблем с понижением параметров. Я все равно склоняюсь к DataEventArgsрешению (лично). Я бы сделал это, но зная, что это избыточно, поскольку отправитель хранится в первом параметре и как свойство аргументов события.

Одно из преимуществ использования DataEventArgsзаключается в том, что вы можете связывать события, изменяя отправителя (для представления последнего отправителя), в то время как EventArgs сохраняет исходного отправителя.

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

public event Action<MyEventType> EventName

откуда MyEventTypeне наследуется EventArgs. Зачем беспокоиться, если я никогда не собираюсь использовать какие-либо члены EventArgs.