Должен ли я использовать несколько событий или более подробный класс eventargs?

Question

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

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

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

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

Должен ли я это сделать?

void receive(byte[] somebytes) 
{ 
    // After checking to make sure all bytes expected are received 
    switch(somecase) 
    { 
     case 0: TriggerEvent(SomeEventArgs);break; 
     case 1: TriggerEvent(SomeEventArgs);break; 
     case 2: TriggerEvent(SomeEventArgs);break; 
     case 3: TriggerEvent(SomeEventArgs);break; 
     case 4: TriggerEvent(SomeEventArgs);break; 
     case 5: TriggerEvent(SomeEventArgs);break; 
     case 6: TriggerEvent(SomeEventArgs);break; 
     case 7: TriggerEvent(SomeEventArgs);break; 
     case 8: TriggerEvent(SomeEventArgs);break; 
    } 
} 

ИЛИ это:

void receive(byte[] somebytes) 
{ 
    // After checking to make sure all bytes expected are received 
    switch(somecase) 
    { 
     case 0: Event0(LessEventArgs);break; 
     case 1: Event1(LessEventArgs);break; 
     case 2: Event2(LessEventArgs);break; 
     case 3: Event3(LessEventArgs);break; 
     case 4: Event4(LessEventArgs);break; 
     case 5: Event5(LessEventArgs);break; 
     case 6: Event6(LessEventArgs);break; 
     case 7: Event7(LessEventArgs);break; 
     case 8: Event8(LessEventArgs);break; 
    } 
} 

Answer 1

Оба решения будут работать, но я думаю, что гораздо проще иметь событие с подписью.

Если у вас есть одно событие, вам просто нужно определить уникальное EventArgs<T> опубликовать одно событие в вашем классе и обработать одно событие.

Все логические решения, которые нужно решить, - это «класс клиента», который сужается к событию. Это упрощает тестирование и отладки.

Таким образом, вы должны были бы:

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

Если вы сделаете это так, очень просто создать единичный тест для тестирования метода диспетчера и различные модульные тесты для тестирования каждого из 8 методов.

Ваш «класс сервера», который зависит от внешних резорбций, прост. Это важно, потому что было бы сложно отладить тест диспетчера, который выбрал между восемью событиями.

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

В качестве примечания, я рекомендую вам прочитать эту полную статью о "C# Event Implementation Fundamentals, Best Practices and Conventions"

Answer 2

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

Answer 3

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

Answer 4

Мое личное предпочтение является «меньше значит больше» подход, и я хотел бы создать одно событие, передавая Enum через EventArgs, как вы описано.

Я бы сравнил это с KeyPressDown в библиотеке .NET для разработки настольных компьютеров. Существует не AKeyPressed, BKeyPressed, EnterKeyPressed - он инкапсулирован в один метод для аккуратной и интуитивно понятной реализации.