2009-10-05 2 views
5

Niedawno dowiedziałem się o Presenter First i czytać ich whitepapers i blogów itdW Presenter First, dlaczego metoda SubscribeSomeEvent na interfejsie jest preferowana do zwykłych starych zdarzeń?

W większości przykładów znalazłem, zdarzenia nie są zgłaszane bezpośrednio w interfejsie, lecz raczej jako sposób na niego. Na przykład:

public interface IPuzzleView 
{ 
    void SubscribeMoveRequest(PointDelegate listener); 
    // vs 
    event PointDelegate MoveRequest; 
} 

Nie rozumiem dokładnie, dlaczego. Wydawało mi się, że widziałem gdzieś papier/artykuł/blog, który wyjaśnia uzasadnienie, ale nie mogę go już znaleźć. Wspomniany tekst zawierał również fragmenty kodu testowania jednostkowego - wiem to, ponieważ pamiętam, że powiedziałem sobie, że jeden z testów jednostkowych był niepoprawny.

UPDATE:

Poniżej jest przykład dla porównania:

public class Collect 
{ 
    public static CollectAction<T> Argument<T>(int index, 
     CollectAction<T>.Collect collectDelegate) 
    { 
     CollectAction<T> collect = new CollectAction<T>(index, collectDelegate); 
     return collect; 
    } 
} 

public interface IApplicationView 
{ 
    event EventHandler Load; 

    // or 

    void SubscribeLoad(Action action); 
} 

Mockery mockery = new Mockery(); 
IApplicationView view = mockery.NewMock<IApplicationView>(); 
IApplicationModel model = mockery.NewMock<IApplicationModel>(); 

Zapisz styl:

Action savedAction = null; 
Expect.Once.On(view).Method("SubscribeLoad").Will(
    Collect.Argument<Action>(0, 
    delegate(Action action) { savedAction = action; })); 
Expect.Once.On(model).Method("LoadModules"); 
new ApplicationPresenter(view, model); 
savedAction(); 
mockery.VerifyAllExpectationsHaveBeenMet(); 

vs. zdarzenia:

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(); 

FYI, powyższy styl zdarzeń nie zadziała tak, jak jest, ponieważ ApplicationPresenter od razu zbiera śmieci i okablowanie nigdy się nie dzieje.

+1

Chciałbym skontaktować się z ludźmi w atomicobject, ponieważ zawierają one większość informacji na ten temat i większość badań została wykonana przez nich. Mogą być w stanie wskazać ci papier, który pamiętasz. –

Odpowiedz

3

Krótka odpowiedź brzmi: Prezenter Pierwsza ewoluowała pierwotnie w dniach .NET 1.1 i VS2003, a zdarzenia C# mogą być problematyczne.

Wcześniejsze narzędzia do testowania/szyderstwa nie potwierdziły naszej potrzeby enkapsulacji subskrypcji zdarzeń i wysyłek. Z biegiem czasu zaczęliśmy odczuwać, że eksponowanie specyfiki zdarzeń poza ich klasami emisyjnymi obciążało kod klienta zbyt dużą wiedzą o implementacji, co utrudniało refaktoryzację.

W opublikowanych przykładach nie chcieliśmy kojarzyć techniki Presenter First z funkcją specyficzną dla języka. (Np. Java nie ma odpowiednika zdarzeń lub delegatów C#, ale to nie znaczy, że nie możesz użyć wzorca Obserwatora.)

Widzę, że wydarzenia, anonimowi delegaci i narzędzia szermiercze przeszli długą drogę w ciągu ostatnich kilku lat. Następnym razem, gdy wybiorę projekt C#, zmienię wszystkie moje założenia na "najlepszy sposób", aby obsłużyć subskrypcję i wysyłkę zdarzeń. Powyższe przykłady są intrygujące.

Podsumowując nasze oryginalne, może stary, powody ukrywania naszego użycia C# zdarzeń: - szyderczy subskrypcji zdarzeń nie było możliwe w jednostce testuje - Czasami chcemy użyć innego mechanizmu wewnętrznego obsłużyć subskrypcji zdarzenie/wysyłki . Doprowadziło to do niespójności między jednym interfejsem a drugim. - Kilka razy zastanawialiśmy się nad porzucaniem zdarzeń C# nawet wewnętrznie, ponieważ zachowywali się inaczej, gdy nie istniały subskrybenci. Odsłonięcie wydarzeń na zewnątrz znacznie utrudniłoby ponowne ich wdrożenie.

Kiedy Jiho Han poinformował mnie o tym pytaniu, zapytał także o powiązanie danych i bardziej dopracowany przykład PF, na który odpowiedziałem publikując a newer, fuller example of Presenter First and elaborating on Adapters.

Powiązane problemy