В Предъявителе Сначала, почему метод SubscribeSomeEvent в интерфейсе предпочтен простым событиям?

Я недавно узнал о Предъявителе Сначала, и прочитайте их технические описания и блоги и т.д.

В большинстве примеров я нашел, события не объявляются непосредственно в интерфейсе, а скорее как метод для него. Например,

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 собран "мусор" сразу же, и проводного соединения никогда не происходит.

5
задан Jiho Han 6 October 2009 в 15:29
поделиться

1 ответ

Короткий ответ: Ведущий впервые развился изначально во времена .NET 1.1 и VS2003, и события на C# могут быть проблематичными.

Тогдашние инструменты тестирования/издевательства не поддерживали необходимость инкапсуляции подписки и рассылки событий. Со временем мы почувствовали, что разоблачение специфики событий вне их эмиссионных классов обременяет клиентский код слишком большим объемом знаний о реализации, что затрудняет рефакторинг.

В случае опубликованных примеров мы хотели избежать ассоциирования техники докладчика First с особенностями языка. (Eg, Java не имеет эквивалента событий на C# или делегатов, но это не значит, что вы не можете использовать шаблон Observer)

Я вижу, что события, анонимные делегаты и инструменты для насмешек за последние несколько лет проделали большой путь. В следующий раз, когда я возьму проект на C#, я заново оценю все свои предположения о "лучшем способе" обработки подписки на события и их рассылки. Приведенные выше примеры являются интригующими.

Подводя итог, можно сказать, что это наши оригинальные, возможно, датированные причины, по которым мы скрываем использование событий на C#: - Издевательская подписка на события была невозможна в юнит-тестах. - Иногда мы использовали другой внутренний механизм для обработки подписки/диспетчеризации событий. Это приводило к несогласованности интерфейсов. - Несколько раз мы рассматривали возможность отказа от C#-событий даже внутри компании, так как при отсутствии подписчиков они вели себя по-другому. Разоблачение событий извне значительно усложнило бы их повторное внедрение.

Когда Джохо Хан послал мне этот вопрос, он также поинтересовался привязкой данных и более плотным примером PF, на который я ответил публикацией более нового, более полного примера Presenter First и развитием Adapters.

4
ответ дан 15 December 2019 в 01:06
поделиться
Другие вопросы по тегам:

Похожие вопросы: