Использует обработчики событий как «многоразовый код»?

Question

Ситуация

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

Хорошо, поэтому есть предварительный код, над которым я работаю, и в этом коде они повторно используют обработчики событий как некоторую форму ООП.

Пример некоторого обработчика событий:

protected void btnSomeButton_Click(object sender, Eventargs e) 
{ 
    //SOME LOGIC 
} 

Пример «повторное использование» вышеуказанного обработчик событий:

Примечания: Это называется в произвольной точке в Web App с точкой повторного использования // НЕКОТОРНОЙ ЛОГИКИ.

{ 
    btnSomeButton_Click(null, null); 
} 

Некоторые моменты для ясности

• Описанный выше метод работает.
• Обработчик событий работает в нормальном смысле.

Что я предполагаю, что должен быть сделан

По моему рассуждению правильного способа сделать это было бы создать отдельный метод и вызывать этот метод при попытке повторного использования кода. (Вы можете исправить меня)

protected void btnSomeButton_Click(object sender, EventArgs e) 
{ 
    somefunction(); 
} 

и повторно использовать код:

{ 
    somefunction() 
} 

метод является что-то вроде этого:

void somefunction() 
{ 
    //SOME LOGIC 
} 

на вопрос | Моя проблема

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

Какова концептуальная причина отсутствия кодирования в способе кодирования первого примера? Или это приемлемо, и я должен просто оставить его?

Answer 1

Я согласен с вашими соображениями о том, чтобы ввести код в отдельную функцию.
Основная проблема, с которой я столкнулся при использовании таких видов повторных операций, состоит в том, что обычно не ожидает что-то, что выглядит как обработчик для события framework, который должен быть , вызываемый чем-то еще чем рамки.
Параметры в вашем примере указывают на очень важный момент: Прямо сейчас они не используются, но это может измениться в будущем. Структура обычно дает определенные гарантии для параметров, например, что они никогда не будут null: при редактировании кода можно сказать «почему я не должен доверять структуре?». и пропустите любые проверки null. Это приведет к ошибке для кода без рамки, который просто проходит null.
Другая проблема, с которой я часто сталкиваюсь, заключается в том, что обработчики могут быть расширены позже с кодом, который нежелателен или даже вреден в случае «ручного» вызова. Простой пример, который приходит на ум, будет записывать что-то вроде кнопки «нажатие кнопки», когда на самом деле пользователь этого не сделал.

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

Answer 2

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

Если этот метод затем вызывается из другого места в коде, передавая его в виде Action<object, EventArgs>, и он тогда называется таким образом, вызывающий код до сих пор не знает о методе до его ввода, поэтому он все еще слабо связан.

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

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