Лучшая практика с обычной обработкой событий

Question

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

например:

ScheduledPatientsGrid.ProcessGridKey += ScheduledPatientsGrid_ProcessGridKey; 
RecentPatientsGrid.ProcessGridKey += RecentPatientsGrid_ProcessGridKey; 
RecentPatientsGrid.ProcessGridKey += RecentPatientsGrid_ProcessGridKey; 

... 

private void ScheduledPatientsGrid_ProcessGridKey(object sender, KeyEventArgs e) 
{ 
    ... 
} 

private void RecentPatientsGrid_ProcessGridKey(object sender, KeyEventArgs e) 
{ 
    ... 
} 

private void PatientsGrid_ProcessGridKey(object sender, KeyEventArgs e) 
{ 
    ... 
} 

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

ScheduledPatientsGrid.ProcessGridKey += ProcessGridKey; 
RecentPatientsGrid.ProcessGridKey += ProcessGridKey; 
RecentPatientsGrid.ProcessGridKey += ProcessGridKey;     


private void ProcessGridKey(object sender, KeyEventArgs e) 
{ 
    ... 
} 

На следующей странице, Microsoft, кажется, предполагает, что совместное использование лучше, однако я заметил, что они не обновили его, так как .NET 2.0 (то есть: Visual Studio 2008)

http://msdn.microsoft.com/en-us/library/4ac48519%28v=vs.90%29.aspx

Есть ли руководство, в котором содержится рекомендация по лучшим практикам в этом случае?

Answer 1

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

Лично я ненавижу соглашение source_EventName, которое порождает Visual Studio. Я предпочитаю давать методам обработчика событий значащие имена, которые говорят, что они do. Затем, когда вы смотрите вниз на список обработчиков событий в дизайнере, вы можете видеть, что при нажатии кнопки происходит X, а не «обработчик события щелчка кнопки будет вызван», что бесполезно.

В качестве альтернативы, используйте лямбда-выражения, чтобы подписаться на события и вызвать значащие методы со значимыми параметрами. (The sender и args зачастую бесполезны для обработчиков событий.)

Answer 2

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

private void ProcessGridKey(object sender, KeyEventArgs e) 
{ 
    if (sender is x) 
      xmethod(); 
    if (sender is y) 
      ymethod(); //etc 
} 

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

Answer 3

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

ScheduledPatientsGrid.ProcessGridKey += ScheduledPatientsGrid_ProcessGridKey; 
RecentPatientsGrid.ProcessGridKey += RecentPatientsGrid_ProcessGridKey; 
RecentPatientsGrid.ProcessGridKey += RecentPatientsGrid_ProcessGridKey; 

... 

private void ScheduledPatientsGrid_ProcessGridKey(object sender, KeyEventArgs e) 
{ 
    ProcessGridKey(e.Key); 
} 

private void RecentPatientsGrid_ProcessGridKey(object sender, KeyEventArgs e) 
{ 
    ProcessGridKey(e.Key); 
} 

private void PatientsGrid_ProcessGridKey(object sender, KeyEventArgs e) 
{ 
    ProcessGridKey(e.Key); 
} 

private void ProcessGridKey(Key e) 
{ 
    ... 
} 

Ваш пробег может изменяться в зависимости о том, что делает общий метод, или о параметрах, переданных в. (Например, в приведенном выше примере я дублирую вытягивание Key с KeyEventArgs.