Das Verständnis von Ereignissen und Ereignishandlern in C#

Question

Ich verstehe den Zweck von Ereignissen, insbesondere im Zusammenhang mit der Erstellung von Benutzeroberflächen. Ich denke, dies ist das Prototyp für die Erstellung eines Ereignisses:

public void EventName(object sender, EventArgs e);

Was machen Ereignishandler, warum werden sie benötigt und wie erstelle ich einen?

Answer 1

Mein Verständnis der Ereignisse ist;

Delegat:

Eine Variable, die auf die Methode(n) verweist, die ausgeführt werden sollen. Dadurch ist es möglich, Methoden wie eine Variable zu übergeben.

Schritte zum Erstellen und Aufrufen des Ereignisses:

1. Das Ereignis ist eine Instanz eines Delegaten

2. Da ein Ereignis eine Instanz eines Delegaten ist, müssen wir zuerst den Delegaten definieren.

3. Die Methode(n) zuweisen, die ausgeführt werden sollen, wenn das Ereignis ausgelöst wird (Aufruf des Delegaten)

4. Das Ereignis auslösen (Delegaten aufrufen)

Beispiel:

using System;

namespace test{
    class MyTestApp{
        //Die Event Handler-Deklaration
        public delegate void EventHandler();

        //Die Event-Deklaration
        public event EventHandler MyHandler;

        //Die aufzurufende Methode
        public void Hello(){
            Console.WriteLine("Hallo Welt der Ereignisse!");
        }

        public static void Main(){
            MyTestApp TestApp = new MyTestApp();

            //Die Methode zuweisen, die aufgerufen werden soll, wenn das Ereignis ausgelöst wird
            TestApp.MyHandler = new EventHandler(TestApp.Hello);

            //Das Ereignis auslösen
            if (TestApp.MyHandler != null){
                TestApp.MyHandler();
            }
        }

    }   

}

Answer 2

//Dieser Delegat kann verwendet werden, um auf Methoden zu verweisen,
//die void zurückgeben und einen String akzeptieren.
public delegate void MyDelegate(string foo);

//Dieses Ereignis kann dazu führen, dass jede Methode aufgerufen wird, die
//MyEventHandler entspricht.
public event MyDelegate MyEvent;

//Hier ist etwas Code, der ausgeführt werden soll,
//wenn SomethingHappened ausgelöst wird.
void MyEventHandler(string foo)
{
    //Etwas tun
}

//Ich erstelle einen Delegaten (Pointer) auf HandleSomethingHappened
//und füge ihn der Liste der "Ereignisbehandler" von SomethingHappened hinzu.
myObj.MyEvent += new MyDelegate(MyEventHandler);

Answer 3

Verlag: wo die Ereignisse stattfinden. Der Verlag sollte angeben, welchen Delegaten die Klasse verwendet und die erforderlichen Argumente generieren, diese Argumente an den Delegaten übergeben und sich selbst übergeben.

Abonnent: wo die Antwort erfolgt. Der Abonnent sollte Methoden angeben, um auf Ereignisse zu reagieren. Diese Methoden sollten dieselbe Art von Argumenten wie der Delegat akzeptieren. Der Abonnent fügt dann diese Methode zum Delegaten des Verlags hinzu.

Daher erhält der Delegat, wenn das Ereignis im Verlag eintritt, einige Ereignisargumente (Daten, usw.), aber der Verlag hat keine Ahnung, was mit all diesen Daten passieren wird. Abonnenten können Methoden in ihrer eigenen Klasse erstellen, um auf Ereignisse in der Klasse des Verlags zu reagieren, sodass Abonnenten auf Ereignisse des Verlags reagieren können.

Answer 4

Ich habe kürzlich ein Beispiel dafür gemacht, wie man Ereignisse in c# verwendet, und es auf meinem Blog veröffentlicht. Ich habe versucht, es so klar wie möglich zu gestalten, mit einem sehr einfachen Beispiel. Falls es jemandem helfen könnte, hier ist es: http://www.konsfik.com/using-events-in-csharp/

Es enthält eine Beschreibung und den Quellcode (mit vielen Kommentaren) und konzentriert sich hauptsächlich auf eine ordnungsgemäße (template-ähnliche) Verwendung von Ereignissen und Ereignishandlern.

Einige wichtige Punkte sind:

• Ereignisse sind "Unterarten von Delegaten", nur strenger (auf positive Weise) eingeschränkt. Tatsächlich beinhaltet die Deklaration eines Ereignisses immer einen Delegaten (EventHandlers sind eine Art von Delegaten).

• Ereignishandler sind spezifische Arten von Delegaten (man könnte an sie als Vorlage denken), die den Benutzer zwingen, Ereignisse zu erstellen, die eine spezifische "Signatur" haben. Die Signatur hat das Format: (object sender, EventArgs ereignisargumente).

• Sie können Ihre eigene Unterklasse von EventArgs erstellen, um jede Art von Informationen einzuschließen, die das Ereignis vermitteln muss. Es ist nicht notwendig EventHandlers zu verwenden, wenn Ereignisse verwendet werden. Sie können sie vollständig überspringen und an ihrer Stelle Ihre eigene Art von Delegat verwenden.

• Ein wichtiger Unterschied zwischen der Verwendung von Ereignissen und Delegaten ist, dass Ereignisse nur aus der Klasse aufgerufen werden können, in der sie deklariert wurden, auch wenn sie als öffentlich deklariert sind. Dies ist ein sehr wichtiger Unterschied, denn er ermöglicht es Ihren Ereignissen, freigelegt zu werden, so dass sie mit externen Methoden "verbunden" sind, während sie gleichzeitig vor "externem Missbrauch" geschützt sind.

Answer 5

Eine weitere Sache, die man wissen sollte, in einigen Fällen müssen Sie Delegates/Events verwenden, wenn Sie eine niedrige Kopplung benötigen!

Wenn Sie eine Komponente an mehreren Stellen in der Anwendung verwenden möchten, müssen Sie eine Komponente mit niedriger Kopplung erstellen und die spezifische nicht beunruhigte LOGIK muss AUSSEN Ihrer Komponente delegiert werden! Dies stellt sicher, dass Sie über ein entkoppeltes System und einen saubereren Code verfügen.

Im SOLID Prinzip ist dies das "D" (Dependency Inversion Principle).

Auch bekannt als "IoC", Inversion of Control.

Sie können "IoC" mit Events, Delegates und DI (Dependency Injection) durchführen.

Es ist einfach, auf eine Methode in einer Kindklasse zuzugreifen. Aber schwieriger, auf eine Methode in einer Elternklasse von Kind aus zuzugreifen. Sie müssen die Verweis des Elternteils an das Kind übergeben! (oder DI mit Interface verwenden)

Delegates/Events ermöglichen es uns, vom Kind zum Elternteil zu kommunizieren, ohne Verweis zu haben!

In diesem obigen Diagramm verwende ich kein Delegate/Event und die Elternkomponente B muss eine Verweis auf die Elternkomponente A haben, um die nicht beunruhigte Geschäftslogik in der Methode von A auszuführen. (hohe Kopplung)

Bei diesem Ansatz müsste ich alle Verweise aller Komponenten hinzufügen, die die Komponente B verwenden! :(

In diesem obigen Diagramm verwende ich Delegate/Event und die Komponente B muss A nicht kennen. (niedrige Kopplung)

Und Sie können Ihre Komponente B überall in Ihrer Anwendung verwenden!