Рекомендации по оформлению мероприятий

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

В какой-то степени это облегчает мою жизнь, поскольку я использую анализ кода для автоматизации проверки мест, где я не могу использовать передовой опыт.

Но вот случай, когда я чувствую себя очень вынужденным просто игнорировать рекомендации.

Поскольку ограничение EventArgs было удалено из EventHandler в .NET 4, зачем кому-то использовать класс, производный от EventArgs (как указано в https://msdn.microsoft.com/en-us/library/ms229011).(v=vs.110).aspx) в настоящее время вместо используя желаемый тип данных напрямую и избегая затрат на выделение другого объекта и встраивание в него нужных данных?

Например, нужно написать следующее:

public class ExceptionEventArgs : EventArgs
{
    private readonly Exception _exception;

    public ExceptionEventArgs(Exception exception)
    {
        _exception = exception;
    }

    public Exception Exception
    {
        get
        {
            return _exception;
        }
    }
}

public event EventHandler<ExceptionEventArgs>;

гораздо более подробный, поскольку требует дополнительного распределения вместо:

public event EventHandler<Exception>;

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

public class EventArgs<T> : EventArgs
{
    private readonly T _data;

    public EventArgs(T data)
    {
        _data = data;
    }

    public T Data
    {
        get
        {
            return _data;
        }
    }
}

Итак, есть ли минусы использования

EventHandler<NotAnEventArgsDerivedClass>

для классов, предназначенных только для внутреннего* использования?

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


.net c# eventargs
person Alfred Myers    schedule 08.04.2016    source источник
comment
Одна любопытная вещь, которую я заметил в этих рекомендациях: почему не рекомендуется создавать собственных делегатов для обработки событий?   -  person Rodrigo Vedovato    schedule 09.04.2016
comment
@RodrigoVedovato: В чем смысл? EventHandler<T> достаточно хорошо.   -  person SLaks    schedule 09.04.2016
comment
stackoverflow.com/questions/6816848/   -  person lukbl    schedule 09.04.2016

Ответы (1)


arrow_upward
1
arrow_downward

Предпочтительно не наследовать от EventArgs. Нет минусов в использовании

EventHandler<NotAnEventArgsDerivedClass>

но он по-прежнему предполагает, что вы хотите передать sender как object, когда может иметь или не иметь смысла передавать sender вообще.

Использование EventArgs - это единственный случай, который я могу придумать, когда обычно наследуют от класса из-за соглашения, когда нам на самом деле не нужен класс, от которого мы наследуем. Точно так же стандартный делегат Handler(object sender, EventArgs e) является единственным известным мне случаем, когда принято разрабатывать сигнатуру метода на основе соглашения, а не требований для этого конкретного метода. Это побуждает нас передавать нетипизированный параметр, когда для нас может иметь или не иметь смысла вообще передавать отправителя. Это приводит к методам, в которых мы игнорируем аргументы, не доверяем значениям аргументов и приводим объекты к более конкретным типам, потому что мы «просто знаем», что они собой представляют на самом деле.

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

person Scott Hannen    schedule 09.04.2016