Имам следното (опростено):
interface IFindFilesObserver
{
void OnFoundFile(FileInfo fileInfo);
void OnFoundDirectory(DirectoryInfo directoryInfo);
}
class FindFiles
{
IFindFilesObserver _observer;
// ...
}
...и съм в конфликт. Това е основно това, което бих написал на C++, но C# има събития. Трябва ли да променя кода, за да използва събития, или трябва да го оставя?
Какви са предимствата или недостатъците на събитията пред традиционния интерфейс за наблюдатели?
Считайте, че събитието е интерфейс за обратно извикване, когато интерфейсът има само един метод.
Само закачащи събития, от които се нуждаете
Със събитията трябва да внедрите манипулатори само за събития, които искате да управлявате. В модела на интерфейса на наблюдателя ще трябва да внедрите всички методи в целия интерфейс, включително внедряване на тела на методи за типове известия, които всъщност не ви интересуват. Във вашия пример винаги трябва да внедрите OnFoundDirectory и OnFoundFile, дори ако ви интересува само едно от тези събития.
По-малко поддръжка
Друго добро нещо при събитията е, че можете да добавите ново към конкретен клас, така че да го повиши, и не е нужно да променяте всеки съществуващ наблюдател. Докато, ако искате да добавите нов метод към интерфейс, трябва да обиколите всеки клас, който вече имплементира този интерфейс, и да внедрите новия метод във всички тях. Със събитие обаче трябва само да промените съществуващите класове, които действително искат да направят нещо в отговор на новото събитие, което добавяте.
Моделът е вграден в езика, така че всеки знае как да го използва
Събитията са идиоматични, тъй като когато видите събитие, знаете как да го използвате. С интерфейс за наблюдател хората често прилагат различни начини за регистриране, за да получават известия и да свързват наблюдателя.. със събития обаче, след като се научите как да се регистрирате и използвате такъв (с оператора +=), останалите са всички един и същ.
Професионалисти за интерфейси
Нямам много плюсове за интерфейси. Предполагам, че принуждават някого да внедри всички методи в интерфейса. Но не можете наистина да принудите някого да приложи всички тези методи правилно, така че не мисля, че има голяма стойност в това.
Синтаксис
Някои хора не харесват начина, по който трябва да декларирате тип делегат за всяко събитие. Освен това стандартните манипулатори на събития в .NET framework имат следните параметри: (изпращач на обект, EventArgs args). Тъй като подателят не посочва конкретен тип, трябва да го направите надолу, ако искате да го използвате. Това често е добре на практика, но не изглежда съвсем правилно, защото губите защитата на системата от статичен тип. Но ако внедрите свои собствени събития и не следвате конвенцията на .NET framework за това, можете да използвате правилния тип, така че не е необходимо потенциално преобразуване надолу.
event Action или event Action<string,int> и т.н.
- person natli; 18.07.2013
Хм, събитията могат да се използват за прилагане на модела на наблюдателя. Всъщност използването на събития може да се разглежда като друга реализация на модела на наблюдателя 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).
Във вашия случай бих казал, че няма голяма разлика. Ако наблюдателят обикновено се интересува от всички тези събития, използвайте интерфейс за наблюдател, а не отделни събития.
Най-добрият начин да решите е следният: кой е по-подходящ за ситуацията. Това може да звучи като глупав или безполезен отговор, но не мисля, че трябва да смятате едното или другото за „правилното“ решение.
Можем да ви дадем стотици съвети. Събитията са най-добри, когато се очаква наблюдателят да слуша за произволни събития. Интерфейсът е най-добър, когато се очаква наблюдателят да посочи всички от даден набор от събития. Събитията са най-добри, когато работите с GUI приложения. Интерфейсите консумират по-малко памет (един указател за множество събития). дяда дяда дяда. Списъкът с плюсове и минуси е нещо, върху което да помислите, но не и окончателен отговор. Това, което наистина трябва да направите, е да опитате и двете в реални приложения и да ги усетите добре. След това можете да изберете този, който е по-подходящ за ситуацията. Научете се да правите формуляри.
Ако трябва да използвате един определящ въпрос, тогава се запитайте кое по-добре описва вашата ситуация: набор от слабо свързани събития, всяко от които може да бъде използвано или пренебрегнато, или набор от тясно свързани събития, които обикновено трябва да бъдат обработени от един наблюдател. Но тогава просто описвам модела на събитието и модела на интерфейса, така че отново съм на изходна позиция: кой отговаря по-добре на ситуацията?
Java има езикова поддръжка за анонимни интерфейси, така че интерфейсите за обратно извикване са нещото, което трябва да се използва в Java.
C# има поддръжка за анонимни делегати - ламбда - и така събитията са нещото, което трябва да се използва в C#.
Предимството на интерфейсите е, че те са по-лесни за прилагане на декоратори. Стандартният пример:
subject.RegisterObserver(new LoggingObserver(myRealObserver));
в сравнение с:
subject.AnEvent += (sender, args) => { LogTheEvent(); realEventHandler(sender, args); };
(Аз съм голям фен на модела декоратор).
Предпочитам решение за основа на събития поради следните причини
Ако вашите обекти ще трябва да бъдат сериализирани по някакъв начин, който запазва препратки, като например с NetDataContractSerializer или може би protobuf събития няма да могат преминават границата на сериализация. Тъй като моделът на наблюдателя не разчита на нищо повече от препратки към обекти, той може да работи с този тип сериализация без проблем, ако това е желаното.
Пр. Имате куп бизнес обекти, които се свързват един с друг двупосочно и които трябва да предадете на уеб услуга.
