events?

Helium

Wozu gibt es in C# das schöne Schlüsselwörtchen 'event'? Es scheint nichts zu tun, als zu verhindern, das man '=' auf dem entstehenden Objekt aufruft.

class Klasse {
   delegate void Foo ();

   event Foo mitEvent;

   Foo ohneEvent;

   void methode ()
   { ...}

   void beispiel ()
   {
      mitEvent  += new Foo (methode);
      ohneEvent += new Foo (methode);

      mitEvent  -= ...
      ohneEvent -= ...

      // mitEvent =  geht nicht
      ohneEvent = ...
   }
};

ISt das verhindern von einer reinen Zuweisung wirklich der einzige Zweck?

Jetzt hast mich beschäftigt.
Also was ich bisher rausgefunden habe ist, dass events virtual sein können.

class Klasse 
{
	private static void Main()
	{
		Klasse foo = new Klasse();
		foo.beispiel();
	}

   protected delegate void Foo ();

   protected virtual event Foo mitEvent;
   protected /*virtual*/ Foo ohneEvent;	// geht net

   private void methode1()
   {
		System.Console.Out.WriteLine("methode1()");
   }

   private void methode2()
   {
		System.Console.Out.WriteLine("methode2()");
   }

   private void beispiel ()
   {
		mitEvent  += methode1;
		ohneEvent += methode1;
		mitEvent  += methode2;
		ohneEvent += methode2;
		mitEvent += delegate {System.Console.Out.WriteLine("anonymous");};
		ohneEvent += delegate {System.Console.Out.WriteLine("anonymous");};

	   mitEvent();
	   ohneEvent();
   }
}

Wird sicher noch ein paar Dinge geben, interessiert mich jetzt auch.

Und Events können in Interfaces auftauchen, was ja nicht ganz ungeschickt ist.

interface Signalgeber
{
	event Foo blubberEvent;
}

class Button : Signalgeber   {}

Ehrlich gesagt ist eigentlich das einzige, was mich überascht, dass bei delegates += geht (und auch funktioniert). Das wusste ich nicht.

Ich stelle mir events wie Methoden vor, mit den beiden sub-methoden += und -=. Die delegates sind der Datentyp, auf dem sie arbeiten. Dass '=' ist auch Absicht. Man soll nur seine eigenen Delegates an- und abmelden und nicht anderweitig die Liste beeinflussen können. Man kann auch das event nicht von außerhalb der Klasse auslösen. Es ist praktisch ein Sprachmittel für Observer.

Optimizer schrieb:

Ich stelle mir events wie Methoden vor, mit den beiden sub-methoden += und -=.

So ähnlich ist es in der Tat, die Methoden heißen halt, add und remove.

public class Button
{
    public event EventHandler Click;

    // ...
}

Der Compiler übersetzt es dann in etwa, wie
wenn du folgendes geschrieben hättest:

public class Button
{
    private EventHandler _Click;

    public event EventHandler Click {
        [MethodImpl(MethodImplOptions.Synchronized)]
        add { 
            _Click = (EventHandler)Delegate.Combine(_Click, value); 
        }

        [MethodImpl(MethodImplOptions.Synchronized)]
        remove { 
            _Click = (EventHandler)Delegate.Remove(_Click, value); 
        }
    }

    // ...
}

Die 1. Version ist eben deutlich einfacher,
wobei die 2. durchaus ihre Berechtigung hat.

Man erkennt klar die Ähnlichkeit zu Propertys, einzig mit dem Unterschied,
dass man immer beide Blöcke schreiben muss, add und remove. Durch die
Ähnlichkeit ist auch klar, warum events virtual sein können, in Interfaces
deklariert werden etc.. Außerdem wird auch besser klar, dass es wirklich nur
ein Konstrukt ist, dass das Delegate vor unerwünschten Veränderungen schützt.
Ein Sprachmittel für das Observer Pattern eben, wie Optimizer bereits erwähnte.

Events Under the Hood

grüße,
ein Hinterweltler