Я недавно узнал о Предъявителе Сначала, и прочитайте их технические описания и блоги и т.д.
В большинстве примеров я нашел, события не объявляются непосредственно в интерфейсе, а скорее как метод для него. Например,
public interface IPuzzleView
{
void SubscribeMoveRequest(PointDelegate listener);
// vs
event PointDelegate MoveRequest;
}
Я не понимаю точно почему. Я думал, что видел статью/статью/блог где-нибудь, которая объясняет обоснование позади этого, но я больше не могу находить его. Упомянутый текст также содержал отрывки кода поблочного тестирования также - я знаю это, потому что я не забываю говорить мне, что один из модульного теста был неправильным.
ОБНОВЛЕНИЕ:
Следующее является примером для сравнения:
public class Collect
{
public static CollectAction Argument(int index,
CollectAction.Collect collectDelegate)
{
CollectAction collect = new CollectAction(index, collectDelegate);
return collect;
}
}
public interface IApplicationView
{
event EventHandler Load;
// or
void SubscribeLoad(Action action);
}
Mockery mockery = new Mockery();
IApplicationView view = mockery.NewMock();
IApplicationModel model = mockery.NewMock();
Подпишите стиль:
Action savedAction = null;
Expect.Once.On(view).Method("SubscribeLoad").Will(
Collect.Argument(0,
delegate(Action action) { savedAction = action; }));
Expect.Once.On(model).Method("LoadModules");
new ApplicationPresenter(view, model);
savedAction();
mockery.VerifyAllExpectationsHaveBeenMet();
по сравнению с Событием:
Expect.Once.On(view).EventAdd("Load", Is.Anything);
Expect.Once.On(model).Method("LoadModules");
new ApplicationPresenter(view, model);
Fire.Event("Load").On(view);
mockery.VerifyAllExpectationsHaveBeenMet();
К вашему сведению стиль события выше не будет работать, как, так как ApplicationPresenter собран "мусор" сразу же, и проводного соединения никогда не происходит.
Короткий ответ: Ведущий впервые развился изначально во времена .NET 1.1 и VS2003, и события на C# могут быть проблематичными.
Тогдашние инструменты тестирования/издевательства не поддерживали необходимость инкапсуляции подписки и рассылки событий. Со временем мы почувствовали, что разоблачение специфики событий вне их эмиссионных классов обременяет клиентский код слишком большим объемом знаний о реализации, что затрудняет рефакторинг.
В случае опубликованных примеров мы хотели избежать ассоциирования техники докладчика First с особенностями языка. (Eg, Java не имеет эквивалента событий на C# или делегатов, но это не значит, что вы не можете использовать шаблон Observer)
Я вижу, что события, анонимные делегаты и инструменты для насмешек за последние несколько лет проделали большой путь. В следующий раз, когда я возьму проект на C#, я заново оценю все свои предположения о "лучшем способе" обработки подписки на события и их рассылки. Приведенные выше примеры являются интригующими.
Подводя итог, можно сказать, что это наши оригинальные, возможно, датированные причины, по которым мы скрываем использование событий на C#: - Издевательская подписка на события была невозможна в юнит-тестах. - Иногда мы использовали другой внутренний механизм для обработки подписки/диспетчеризации событий. Это приводило к несогласованности интерфейсов. - Несколько раз мы рассматривали возможность отказа от C#-событий даже внутри компании, так как при отсутствии подписчиков они вели себя по-другому. Разоблачение событий извне значительно усложнило бы их повторное внедрение.
Когда Джохо Хан послал мне этот вопрос, он также поинтересовался привязкой данных и более плотным примером PF, на который я ответил публикацией более нового, более полного примера Presenter First и развитием Adapters.