При разработке производного класса, там [скидка] преимущества для добавления обработчика к событию базового класса в ctor
по сравнению с переопределением OnEventName()
метод и добавляющий некоторое поведение (а также называющий базовый метод), если нельзя изменить базовый метод и не заботитесь в том, что вещи порядка происходят, но только хотят допускающий повторное использование компонент с небольшим дополнительным поведением?
public abstract class BaseClass
{
public event EventHandler SomeEvent;
protected void OnSomeEvent(object sender, EventArgs e)
{
// do some stuff
}
}
public class DerivedA
{
protected override void OnSomeEvent(object sender, EventArgs e)
{
// do some other stuff
base.OnSomeEvent(sender, e);
}
}
public class DerivedB
{
public DerivedB()
{
SomeEvent += (o,e) => { // do some other stuff };
}
}
Вы уже упомянули порядок, в котором вызываются вещи. Некоторые другие вещи, которые, по общему признанию, происходят не так часто, но могут быть важными (исходя из того факта, что базовый класс управляет тем, как вызываются обработчики событий):
В общем, я склонен рассматривать события как происходящие исключительно для пользователей класса, с хорошо спроектированным классом, имеющим виртуальные On ...
методы для подклассов.
Нет никаких значительных преимуществ / недостатков у любого подхода.
Есть несколько различий между подпиской на событие и переопределением метода базового класса. Например, если вы хотите, чтобы какой-то код выполнялся до или после всех других обработчиков, вам действительно следует переопределить метод OnSomeEvent
, поскольку иначе невозможно гарантировать это. Но вы указываете, что вас это не волнует.
В общем, переопределение метода - это то, что требует хорошего понимания поведения базового класса, чтобы гарантировать, что вы ничего непреднамеренно не сломаете. Подписка на событие - это менее навязчивое расширение, и это то, что (предположительно) запланировал разработчик базового класса.
Иногда люди утверждают, что производительность лучше, если преобладать над - но я не верю этому аргументу. Производительность имеет значение только тогда, когда она имеет значение . Разница здесь, вероятно, настолько незначительна, что следует больше беспокоиться о простоте, правильности и простоте обслуживания, а не о производительности.