Besseres Event-Handling

    • C#
    • .NET 5–6

    Es gibt 2 Antworten in diesem Thema. Der letzte Beitrag () ist von φConst.

      Besseres Event-Handling

      -1-

      Der Titel mag ein wenig voreingenommen klingen, ist er auch, dennoch soll nachfolgend eine alternative Art des Event-Handlings gezeigt werden, die ganz ohne "event" keywords oder Delegates auskommt.

      Warum überhaupt alternatives Event-Handling?
      Weil die Art und Weise wie es aktuell gehandhabt wird (events, delegates und +=) insofern obsolet ist, dass diese sich nur sehr mühselig a) warten, b) verändern und c) isolieren lassen.
      Ziel ist einer losere Kopplung, sodass im Idealfall Änderungen in einer Klasse (etwa Event-Sender) nicht auf Änderungen in vielen anderen Klassen auswirkt. Ferner soll das Event-Handling im Allgemeinen viel flexibler möglich sein, als es momentan der Fall ist.

      Wie?
      Ganz simpel: Dependency-Injection. Eine event-werfende Klasse muss eine Referenz auf ein bestimmtes Interface halten. Es ist nun die Aufgabe einer übergeordnete Manager-Klasse, diese Referenz zu setzen.
      Möchte die Klasse nun ein Event werfen, muss diese lediglich die im Interface hinterlegte Methode (.Notify) aufrufen, und alle Klassen die Event-Empfänger sein wollen, werden benachrichtigt: Sender und Empfänger sind jeweils von einander entkoppelt.


      Source
      Spoiler anzeigen

      C#-Quellcode

      1. public sealed class NSEM
      2. {
      3. private static NSEM instance;
      4. public static NSEM Default()
      5. {
      6. if (instance == null)
      7. instance = new NSEM();
      8. return instance;
      9. }
      11. private Dictionary<Type, List<object>> typeInstances;
      12. private NSEM()
      13. {
      14. this.typeInstances = new Dictionary<Type, List<object>>();
      15. }
      17. public void Subscribe(object instance)
      18. {
      19. foreach (var irfc in Helper.GetNotificationReceivers(instance))
      20. {
      21. if (!typeInstances.ContainsKey(irfc))
      22. typeInstances.Add(irfc, new List<object>());
      24. typeInstances[irfc].Add(instance);
      25. }
      27. }
      29. public void Unsubscribe(object instance)
      30. {
      31. this.typeInstances[instance.GetType()].Remove(instance);
      33. }
      35. public IEnumerable<object> GetRelevantInstances<S>()
      36. {
      37. var instances = typeInstances[typeof(S)];
      38. for (int i = 0; i < instances.Count; i++)
      39. yield return instances[i];
      40. }
      42. public dynamic New<T>(params dynamic[]? arguments)
      43. {
      44. object[] injectedArguments = new object[arguments.Length + 1];
      45. injectedArguments[0] = new BasicNotificationAdapter<T>();
      46. Array.Copy(arguments, 0, injectedArguments, 1, arguments.Length);
      48. return Activator.CreateInstance(typeof(T), injectedArguments);
      49. }
      50. }

      C#-Quellcode

      1. public static class Helper
      2. {
      3. private static string INTERFACE_NAME = typeof(INotificationReceiver<dynamic>).Name;
      4. public static IEnumerable<Type> GetNotificationReceivers(object instance)
      5. {
      6. Type type = instance.GetType();
      8. foreach (var irfc in type.GetInterfaces())
      9. {
      10. string name = irfc.Name;
      11. if (name.Equals(INTERFACE_NAME))
      12. yield return irfc;
      13. }
      15. }
      16. }



      Das ist die so eben genannte Manager-Klasse. Soll eine neue event-werfende Klasse instanziiert werden, geschieht das über die Methode .New<T>().

      Die notwendigen Interfaces sehen so aus:

      Spoiler anzeigen

      C#-Quellcode

      1. public interface INotificationReceiver<T>
      2. {
      3. void Notify(object sender, T argument);
      4. }

      C#-Quellcode

      1. public interface INotificationAdapter
      2. {
      3. void Notify<S>(object sender, dynamic argument);
      4. }



      Ein möglicher (zu "injizierender") INotificationAdapter kann etwa so aussehen:

      Spoiler anzeigen

      C#-Quellcode

      1. public class BasicNotificationAdapter<P> : INotificationAdapter
      2. {
      3. public void Notify<S>(object sender, dynamic argument)
      4. {
      5. foreach (dynamic instance in NSEM.Default().GetRelevantInstances<S>())
      6. instance.Notify(sender, argument);
      7. }
      8. }



      Events lassen sich jetzt sehr leicht realisieren.

      Beispiel Sender-Klasse:
      Spoiler anzeigen

      C#-Quellcode

      1. class TestSender
      2. {
      3. INotificationAdapter adapter;
      4. public TestSender(INotificationAdapter adapter)
      5. {
      6. this.adapter = adapter;
      7. }
      9. public void Press()
      10. {
      11. this.adapter.Notify<INotificationReceiver<Guid>>(this, Guid.NewGuid());
      12. this.adapter.Notify<INotificationReceiver<int>>(this, 191);
      13. }
      14. }


      Der Sender muss lediglich eine Referenz auf INotificationAdapter halten, über den Konstruktor wird diese dann von der Manager-Klasse instanziiert.
      Möchte der Sender nun ein Event auslösen, so muss dieser jetzt .Notify() aufrufen und dann lediglich die Event-Meldung spezifizieren.

      Beispiel Empfänger-Klassen:
      Spoiler anzeigen

      C#-Quellcode

      1. public class TestSubscriberGuidListener : INotificationReceiver<Guid>
      2. {
      3. public TestSubscriberGuidListener()
      4. {
      5. NSEM.Default().Subscribe(this);
      6. }
      7. public void Notify(object sender, Guid argument)
      8. {
      9. Console.WriteLine("Notified with " + argument + " by " + sender);
      10. }
      11. }
      13. public class TestSubscriberIntListener : INotificationReceiver<int>
      14. {
      15. public TestSubscriberIntListener()
      16. {
      17. NSEM.Default().Subscribe(this);
      18. }
      19. public void Notify(object sender, int argument)
      20. {
      21. Console.WriteLine("Notified with " + argument + " by " + sender);
      22. }
      23. }


      Im Konstruktor muss jetzt nur noch angegeben werden, dass man auf Events lauschen möchte, ferner die Interface implementiert und die auf die zu lauschende Meldung spezifiziert werden.

      Die Ausführung sieht dann so aus:

      C#-Quellcode

      1. class Program
      2. {
      3. static void Main(string[] args)
      4. {
      5. TestSender sender = NSEM.Default().New<TestSender>();
      7. TestSubscriberGuidListener guidListener = new TestSubscriberGuidListener();
      8. TestSubscriberIntListener intListener = new TestSubscriberIntListener();
      10. sender.Press();
      11. Console.Read();
      12. }
      13. }


      Die Empfänger-Klassen kennen nicht den Sender, der Sender kennt nicht die Empfänger. Änderungen auf einen, oder gar beiden Seiten rufen keine tiefergreifenden Nachwirkungen hervor.

      Ergebnis:


      Jener Empfänger, der auf Guid-artige Meldungen lauscht, empfängt die Guid-Meldung, analog empfängt jener anderer der auf int-artige Meldungen wartet, die int-Meldung.
      _
      Und Gott alleine weiß alles am allerbesten und besser.

      Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „φConst“ ()

      Ich bin wohl derzeit geistig nicht in der Lage, den Nutzen nachzuvollziehen. Kannst Du das mal anhand eines … gängigen Beispiels (Button_Click?) ummünzen? Also CustomButtonKlasse sendet Click und FormKlasse empfängt.
      btw: Wofür steht NSEM?
      Wofür steht irfc in foreach (var irfc in Helper.GetNotificationReceivers(instance))
      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

      Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

      Kannst Du das mal anhand eines … gängigen Beispiels (Button_Click?) ummünzen? Also CustomButtonKlasse sendet Click und FormKlasse empfängt.

      Siehe NSEventDemo.zip


      Wofür steht irfc

      Interface
      Und Gott alleine weiß alles am allerbesten und besser.