del linguaggio C# Design: implementazione dell'interfaccia esplicita di un evento

Question

Piccolo domanda su C design # lingua :))

Se avessi un'interfaccia simile a questo:

interface IFoo { 
    int Value { get; set; } 
} 

E 'possibile implementare in modo esplicito tale interfaccia utilizzando C# 3.0 proprietà auto-implementato:

sealed class Foo : IFoo { 
    int IFoo.Value { get; set; } 
} 

Ma se dovessi un evento nell'interfaccia:

interface IFoo { 
    event EventHandler Event; 
} 

E cercando di attuare in modo esplicito utilizzando campo simile evento:

sealed class Foo : IFoo { 
    event EventHandler IFoo.Event; 
} 

mi metterò il seguente errore del compilatore:

error CS0071: An explicit interface implementation of an event must use event accessor syntax

Credo che gli eventi sul campo come è il una sorta di dualismo per le proprietà auto-implementate.

Quindi la mia domanda è: qual è il motivo di progettazione per tale restrizione fatto?

Answer 1

Credo che potrebbe avere a che fare con il fatto che non si può chiamare un'implementazione dell'interfaccia esplicita dagli altri membri della classe:

public interface I 
{ 
    void DoIt(); 
} 

public class C : I 
{ 
    public C() 
    { 
     DoIt(); // error CS0103: The name 'DoIt' does not exist in the current context 
    } 

    void I.DoIt() { } 
} 

Si noti che è possibile chiamare il metodo tramite upcasting all'interfaccia prima: ((I)this).DoIt();. Un po 'brutto ma funziona.

Se gli eventi potrebbero essere implementati in modo esplicito come suggerito da ControlFlow (l'OP), come li aumenteresti effettivamente? Considerare:

public interface I 
{ 
    event EventHandler SomethingHappened; 
} 

public class C : I 
{ 
    public void OnSomethingHappened() 
    { 
     // Same problem as above 
     SomethingHappened(this, EventArgs.Empty); 
    } 

    event EventHandler I.SomethingHappened; 
} 

Qui non si può nemmeno alzare l'evento upcasting all'interfaccia prima, perché gli eventi possono essere sollevati solo dall'interno della classe che implementa. Sembra quindi perfettamente logico richiedere la sintassi dell'accessorio per eventi esplicitamente implementati.

Answer 2

Interessante domanda. Ho fatto un po 'di ricerche sull'archivio delle note linguistiche e ho scoperto che questa decisione è stata presa il 13 ottobre 1999, ma le note non giustificano la decisione.

Al di sopra della mia testa non vedo alcun motivo teorico o pratico per cui non potremmo avere eventi esplicitamente implementati simili a campi. Né vedo alcun motivo per cui ne abbiamo particolarmente bisogno. Questo potrebbe dover rimanere uno dei misteri dell'ignoto.

Answer 3

Quando si implementa esplicitamente un evento dichiarato in un'interfaccia, è necessario utilizzare manualmente fornire l'aggiunta e la rimozione di accessors di eventi forniti in genere dal compilatore. Il codice di accesso può connettere l'evento di interfaccia a un altro evento della classe o al proprio tipo di delegato.

Ad esempio, questo attiverà l'errore CS0071:

public delegate void MyEvent(object sender); 

interface ITest 
{ 
    event MyEvent Clicked; 
} 

class Test : Itest 
{ 
    event MyEvent ITest.Clicked; // CS0071 
    public static void Main() { } 
} 

Il modo corretto sarebbe:

public delegate void MyEvent(object sender); 

interface ITest 
{ 
    event MyEvent Clicked; 
} 

class Test : Itest 
{ 
    private MyEvent clicked; 

    event MyEvent Itest.Clicked 
    { 
     add 
     { 
      clicked += value; 
     } 

     remove 
     { 
      clicked -= value; 
     } 
    } 

    public static void Main() { } 
} 

vedere Compiler Error CS0071

Answer 4

Questo non sarebbe in realtà un pensiero originale da solo.

Tuttavia, ho pensato che avrei potuto rispondere a questo:

"Off the top of my head I don't see any theoretical or practical reason why we could not have field-like explicitly implemented events. Nor do I see any reason why we particularly need to. This may have to remain one of the mysteries of the unknown." -Eric Lippert

---

Nel capitolo 23 di Introduzione A di programmazione per C#, seconda edizione, Eric Gunnerson ha scritto:

"[I]f another class also wanted to be called when the button was clicked, the += operator could be used, like this:

button.Click += new Button.ClickHandler(OtherMethodToCall);

Unfortunately, if the other class wasn't careful, it might do the following:

button.Click = new Button.ClickHandler(OtherMethodToCall);

This would be bad, as it would mean that our ButtonHandler would be unhooked and only the new method would be called."

...

"What is needed is some way of protecting the delegate field so that it is only accessed using += and -=."

---

Egli continua nelle prossime pagine per commentare comprendente la maggiorazione() e rimuovere() per implementare questo comportamento; essere in grado di scrivere direttamente su questi metodi e le conseguenze dell'allocazione dello spazio di archiviazione per i riferimenti dei delegati non necessari.

Vorrei aggiungere altro, ma rispetto troppo l'autore per farlo senza il suo permesso. Raccomando di trovare una copia di questo libro e consiglierei qualsiasi cosa di Eric Gunnerson in generale (blog, ecc ...)

In ogni caso, spero che questo sia pertinente all'argomento e se è così, spero che appaia chiaro su questo " mistero dell'ignoto "? (Stavo leggendo questo stesso capitolo e ho cercato Stack Overflow per approfondire le considerazioni sulla logica del gestore di eventi durante la creazione di collezioni personalizzate da oggetti personalizzati) - Lo dico solo perché non rivendico alcuna autorità specifica su questo particolare argomento. Io sono solo uno studente in cerca di "illuminazione" me :-)