У меня есть следующее (упрощенное):
interface IFindFilesObserver
{
void OnFoundFile(FileInfo fileInfo);
void OnFoundDirectory(DirectoryInfo directoryInfo);
}
class FindFiles
{
IFindFilesObserver _observer;
// ...
}
... и я в противоречии. Это в основном то, что я написал бы на C++, но в C# есть события. Должен ли я изменить код для использования событий или оставить его в покое?
Каковы преимущества или недостатки событий по сравнению с традиционным интерфейсом наблюдателя?
Рассмотрим событие как интерфейс обратного вызова, где интерфейс имеет только один метод.
Перехватывайте только те события, которые вам нужны
Что касается событий, вам нужно реализовать обработчики только тех событий, которые вы хотите обработать. В шаблоне интерфейса наблюдателя вам нужно будет реализовать все методы во всем интерфейсе, включая реализацию тел методов для типов уведомлений, которые вам на самом деле не нужны. В вашем примере вам всегда нужно реализовывать OnFoundDirectory и OnFoundFile, даже если вам нужно только одно из этих событий.
Меньше обслуживания
Еще одним преимуществом событий является то, что вы можете добавить новое событие к определенному классу, чтобы оно подняло его, и вам не нужно менять каждого существующего наблюдателя. Тогда как, если вы хотите добавить новый метод в интерфейс, вы должны обойти каждый класс, который уже реализует этот интерфейс, и реализовать новый метод во всех них. Однако с событием вам нужно только изменить существующие классы, которые действительно хотят что-то сделать в ответ на новое событие, которое вы добавляете.
Шаблон встроен в язык, поэтому все знают, как его использовать
События идиоматичны, когда вы видите событие, вы знаете, как его использовать. С интерфейсом наблюдателя люди часто реализуют различные способы регистрации для получения уведомлений и подключения наблюдателя. такой же.
Плюсы за интерфейсы
У меня не так много плюсов в интерфейсах. Я предполагаю, что они заставляют кого-то реализовывать все методы в интерфейсе. Но вы не можете заставить кого-то правильно реализовать все эти методы, поэтому я не думаю, что в этом есть большая ценность.
Синтаксис
Некоторым людям не нравится способ объявления типа делегата для каждого события. Кроме того, стандартные обработчики событий в .NET Framework имеют следующие параметры: (отправитель объекта, аргументы EventArgs). Поскольку отправитель не указывает конкретный тип, вам необходимо выполнить приведение вниз, если вы хотите его использовать. На практике это часто хорошо, но кажется не совсем правильным, потому что вы теряете защиту статической системы типов. Но если вы реализуете свои собственные события и не следуете соглашению платформы .NET, вы можете использовать правильный тип, чтобы не требовалось потенциальное приведение вниз.
event Action или event Action<string,int> и т. д.
- person natli; 18.07.2013
Хм, события можно использовать для реализации паттерна Observer. По сути, использование событий можно рассматривать как еще одну реализацию паттерна-обозревателя imho.
События обрабатываются в 2 раза медленнее, чем простой вызов функции, в 3 раза медленнее, если вы выполняете нулевую проверку при каждом подъеме и копируете делегат события перед нулевой проверкой и вызовом, чтобы сделать его потокобезопасным.
Также прочитайте MSDN о новом (в версии 4.0) IObserver<T> интерфейсе.
Рассмотрим этот пример:
using System;
namespace Example
{
//Observer
public class SomeFacade
{
public void DoSomeWork(IObserver notificationObject)
{
Worker worker = new Worker(notificationObject);
worker.DoWork();
}
}
public class Worker
{
private readonly IObserver _notificationObject;
public Worker(IObserver notificationObject)
{
_notificationObject = notificationObject;
}
public void DoWork()
{
//...
_notificationObject.Progress(100);
_notificationObject.Done();
}
}
public interface IObserver
{
void Done();
void Progress(int amount);
}
//Events
public class SomeFacadeWithEvents
{
public event Action Done;
public event Action<int> Progress;
private void RaiseDone()
{
if (Done != null) Done();
}
private void RaiseProgress(int amount)
{
if (Progress != null) Progress(amount);
}
public void DoSomeWork()
{
WorkerWithEvents worker = new WorkerWithEvents();
worker.Done += RaiseDone;
worker.Progress += RaiseProgress;
worker.DoWork();
//Also we neede to unsubscribe...
worker.Done -= RaiseDone;
worker.Progress -= RaiseProgress;
}
}
public class WorkerWithEvents
{
public event Action Done;
public event Action<int> Progress;
public void DoWork()
{
//...
Progress(100);
Done();
}
}
}
Плюсы интерфейсного решения:
Минусы:
Некоторые дополнительные преимущества событий.
Вы можете достичь всего этого (кроме цепочки инструментов) самостоятельно, но это на удивление сложно. Например: если вы используете переменную-член, например List‹>, для хранения списка наблюдателей. Если вы используете foreach для итерации по нему, то любая попытка добавить или удалить подписчика в одном из обратных вызовов метода OnFoo() вызовет исключение, если вы не напишете дополнительный код для его корректной обработки.
Плюсы в том, что события более «точечные». Если вы разрабатываете невизуальные компоненты, которые можно перетаскивать на форму, вы можете подключить их с помощью конструктора.
Минусы в том, что событие означает только одно событие - вам нужно отдельное событие для каждой «вещи», о которой вы хотите уведомить наблюдателя. На самом деле это не имеет большого практического значения, за исключением того, что каждый наблюдаемый объект должен будет содержать ссылку для каждого наблюдателя для каждого события, раздувая память в случае, когда имеется много наблюдаемых объектов (одна из причин, по которой они сделали другой способ хранения). управление отношениями наблюдатель/наблюдаемый в WPF).
В вашем случае я бы сказал, что это не имеет большого значения. Если наблюдателя обычно интересуют все эти события, используйте интерфейс наблюдателя, а не отдельные события.
Лучший способ решить это: какой из них лучше подходит к ситуации. Это может показаться глупым или бесполезным ответом, но я не думаю, что вы должны рассматривать одно или другое как «правильное» решение.
Мы можем подкинуть вам сотню советов. События лучше всего подходят, когда ожидается, что наблюдатель будет прослушивать произвольные события. Интерфейс лучше всего подходит, когда ожидается, что наблюдатель будет перечислять все заданное множество событий. События лучше всего подходят для приложений с графическим интерфейсом. Интерфейсы потребляют меньше памяти (один указатель на несколько событий). Ядда ядда ядда. Маркированный список плюсов и минусов — это повод задуматься, но не окончательный ответ. Что вам действительно нужно сделать, так это попробовать оба из них в реальных приложениях и получить хорошее представление о них. Затем вы можете выбрать тот, который лучше подходит к ситуации. Научитесь делать форму.
Если вам нужно использовать один определяющий вопрос, спросите себя, что лучше описывает вашу ситуацию: набор слабо связанных событий, любое из которых может быть использовано или проигнорировано, или набор тесно связанных событий, которые, как правило, должны обрабатываться один наблюдатель. Но тогда я просто описываю модель событий и модель интерфейса, так что я возвращаюсь к исходной точке: какая из них лучше подходит к ситуации?
В Java есть языковая поддержка анонимных интерфейсов, поэтому в Java лучше всего использовать интерфейсы обратного вызова.
В C# есть поддержка анонимных делегатов — лямбда-выражений, поэтому в C# лучше всего использовать события.
Преимущество интерфейсов в том, что к ним легче применять декораторы. Стандартный пример:
subject.RegisterObserver(new LoggingObserver(myRealObserver));
по сравнению с:
subject.AnEvent += (sender, args) => { LogTheEvent(); realEventHandler(sender, args); };
(Я большой поклонник шаблона декоратора).
Я предпочитаю решение на базе событий по следующим причинам.
Если ваши объекты должны быть сериализованы каким-то образом, сохраняющим ссылки, например, с помощью NetDataContractSerializer или, возможно, события protobuf не смогут пересечь границу сериализации. Поскольку шаблон наблюдателя опирается не более чем на ссылки на объекты, он может без проблем работать с этим типом сериализации, если это необходимо.
Бывший. У вас есть куча бизнес-объектов, которые двунаправленно ссылаются друг на друга, и вам нужно передать их веб-службе.
