Czy wywołanie metody rozszerzenia na odwołaniu "zerowym" (np. Zdarzenie bez subskrybentów) jest złe?

Question

Zło czy nie zło?

public static void Raise(this EventHandler handler, object sender, EventArgs args) 
{ 
    if (handler != null) 
    { 
     handler(sender, args); 
    } 
} 

// Usage: 
MyButtonClicked.Raise(this, EventArgs.Empty); 

// This works too! Evil? 
EventHandler handler = null; 
handler.Raise(this, EVentArgs.Empty); 

Należy pamiętać, że ze względu na charakter metod rozszerzających, MyButtonClicked.Raise nie rzuci NullReferenceException jeśli MyButtonClicked jest null. (Np. Nie ma słuchaczy zdarzenia MyButtonClicked).

Zło czy nie?

Answer 1

Nie zło. Szkoda, że ​​wydarzenia nie działały w ten sposób domyślnie. Czy ktoś może wyjaśnić, dlaczego wydarzenie bez subskrybentów ma wartość zerową?

Answer 2

Dlaczego to byłoby złe?

Jego cel jest jasny: Podnosi zdarzenie MyButtonClicked.

Dodaje narzut funkcji, ale w .NET albo zostanie zoptymalizowany, albo całkiem szybki.

To jest trochę trywialne, ale rozwiązuje moją największą skargę za pomocą C#.

Podsumowując, uważam, że to fantastyczny pomysł i prawdopodobnie go ukradnie.

Answer 3

Zawsze można zadeklarować zdarzeń jak to (nie, że ja go polecam):

public event EventHandler<EventArgs> OnClicked = delegate { }; 

ten sposób mają coś przypisaną do nich, kiedy je połączyć, żeby nie rzucać wyjątku null pointer .

Prawdopodobnie można pozbyć się hasła delegata w C# 3.0 ...

Answer 4

Nie powiedziałbym, że to złe, ale jestem zainteresowany w jaki sposób metoda rozszerzenie pasuje do

protected virtual OnSomeEvent(EventArgs e){ } 

wzór i sposób, w jaki obsługuje on rozszerzalność poprzez dziedziczenie. Czy zakłada, że ​​wszystkie podklasy będą obsługiwać zdarzenie zamiast przesłonić metodę?

Answer 5

Pochodzenie z tła Java zawsze wydawało mi się dziwne. Myślę, że nikt nie słuchający wydarzenia jest całkowicie poprawny. Zwłaszcza, gdy słuchacze są dodawane i usuwane dynamicznie.

Dla mnie jest to jeden z gottch C#, który powoduje błędy, gdy ludzie nie wiedzą/zapominają sprawdzić za każdym razem wartość zerową.

Ukrywanie tego szczegółu implementacji wydaje się dobrym planem, ponieważ nie pomaga w czytelności sprawdzania wartości zerowych za każdym razem. Jestem pewien, że MSFT powiedzą, że jest wzrost wydajności w nie konstytuowaniu zdarzenia, jeśli nikt nie słucha, ale imho jest on znacznie przeważany przez bezsensowny wskaźnik zerowy wyjątków/zmniejszenie czytelności w większości kodów biznesowych.

Chciałbym również dodać te dwie metody do klasy:

public static void Raise(this EventHandler handler, object sender) 
    { 
     Raise(handler, sender, EventArgs.Empty); 
    } 

    public static void Raise<TA>(this EventHandler<TA> handler, object sender, TA args) 
     where TA : EventArgs 
    { 
     if (handler != null) 
     { 
      handler(sender, args); 
     } 
    } 

Answer 6

Nie zapomnij użyć [MethodImpl(MethodImplOptions.NoInlining)], inny jego możliwe, że nie jest bezpieczeństwo wątków.

(Przeczytany że gdzieś dawno temu, pamiętał, google i znalazłem http://blog.quantumbitdesigns.com/tag/events/)

Answer 7

Chociaż nie describ go jako złego, to nadal ma negatywny wpływu, jak dodaje niepotrzebny narzut:

dzwoniąc

myEvent.Raise(this, new EventArgs());

się EventArgs obiekt jest zainicjowany w każdej sytuacji, nawet jeśli nikt subskrybowanych myEvent.

Podczas korzystania

if (myEvent!= null) { 
    myEvent(this, new EventArgs()); 
} 

EventArgs jest inicjowana tylko jeśli ktoś subskrybuje myEvent.

Answer 8

Wyrzucenie wyjątku, gdy nie ma obsługi, nie jest najbardziej pożądane. Jeśli nie ma instrukcji obsługi, lepiej być pustym niż zerowym.