Pattern um Nachrichten aus einer lib zu erhalten

Hi Leute,

ich arbeite gerade an einer Lib und moechte diese fuer zukuenftige Nutzer so konform wie moeglich gestalten.

Nun soll die Lib den Status der Prozesse an das ausfuehrende Programm weitergeben bzw. es soll moeglich sein diese sich zu holen, um diese dann z.B. auf der GUI anzuzeigen.
Dazu faellt mir aber nur das Observer-Modell ein.

Habt ihr vielleicht Ideen dafuer oder ein paar Stichwoerter nach denen ich mich umsehen kann?

Mit besten Gruessen,
Lucy

P.S. Sorry fuer den komischen Titel. Mir fiel nichts besseres ein. 😃

Hi,

nun ja - da sollte man sich wohl am besten an .NET-Standards anlehnen, welche ja auch auf dem Observer-Pattern aufbauen.

Hängt zwar sicher viel davon ab, was das für Nachrichten sind - aber prinzipiell definiert man ein event mit passenden EventArgs und jeder der mag kann sich an das event dranhängen und bekommt entsprechende Nachrichten.

Oder wo hängts genau?

LG

Die moderne Alternative zu Events sind die Reactive Extensions.
Intro To Rx ist eine tolle Webseite dazu.

Ich habe bisher noch nicht mit Observer gearbeitet, kenne jedoch das Prinzip.

Und als ich mich ueber das Thema mit einem Freund unterhalten habe, meinte er, dass dies bei idR. einem Client sich nicht lohnt.
Er gab mir dann noch Stichwoerter wie aspektorientieres Programmieren und libs log4net mit, was mich nicht so recht zufrieden gestellt hat.

Nun bevor ich jetzt etwas anfange was zu "maechtig" fuer mein Vorhaben ist, dachte ich mir, fragst du mal die Community. 😃

Aber ich denke, dass ich schon auf dem richtigen Weg war. Mein Kumpel hat mich wohl etwas verunsichert.

Danke, Taipi88!

Die moderne Alternative zu Events sind die Reactive Extensions.

Oh, werde ich mir gleich mal angucken. Habe auch schon gesehen, dass es wohl auch fuer Mono gibt. Vielen Dank!

VG,
Lucy

Zwei Hinweise:

• mit externen Libraries bzgl. der Kommunikation kann man sich schnell einen Monolithen ins Haus holen
• Mono ist de facto tot und wird durch .NET Core ersetzt werden.

In Java gibt es keine Delegates/Events - da musst Du dann den Observer als eigenständige Klasse implementieren und da gebe ich Deinem Freund recht, daß dort sich der Aufwand nicht immer lohnt. In C# ist das anders.

Zwei Hinweise:

• mit externen Libraries bzgl. der Kommunikation kann man sich schnell einen Monolithen ins Haus holen
• Mono ist de facto tot und wird durch .NET Core ersetzt werden.

Danke! 😃 Vor allem wegen Ersteres, werde ich mir mal genauer ueberlegen wie und was ich umsetze.

Zum zweiten Punkt: Bin recht neu auf einer Linux-Maschine unterwegs. Werde mich mal mehr informieren. War mir nicht bewusst.

In Java gibt es keine Delegates/Events - da musst Du dann den Observer als eigenständige Klasse implementieren und da gebe ich Deinem Freund recht, daß dort sich der Aufwand nicht immer lohnt. In C# ist das anders.

Das ergibt Sinn. 😃 Er hat zwar frueher in C# programmiert, ist aber seit laengerem mit Java unterwegs.

Danke, fuer eure Antworten!

Viele Gruesse,
Lucy

Hier mein Loesungsansatz mit Reactive Extensions. Vielleicht ist das fuer den einen oder anderen nuetzlich. 😃

StatusReporter Class

public static class StatusReporter {

		private static Subject<string> _statusReporterSubscription = new Subject<string>();

		/// <summary>
		/// Fires a new Status report
		/// </summary>
		/// <param name="message">Message.</param>
		public static void NewReport(string report) {
			StatusReporterSubscription.OnNext (report);
		}

		/// <summary>
		/// Subscribe here ;)
		/// StatusReporterSubscriptioner.Subscribe(x => {...});
		/// </summary>
		/// <value>The status reporter subscription.</value>
		public static Subject<string> StatusReporterSubscription {
			get {
				return _statusReporterSubscription;
			}
		}
	}
}

Subscribe

               
                //Subscribe StatusReporter
		StatusReporter.StatusReporterSubscription.Subscribe(x => {
			this.UpdateStatusBar(x);
		});

Neue Nachricht senden.

StatusReporter.NewReport ("Begin decompiling");

Viele Gruesse,
Lucy

Hm, vielleicht bin ich ja etwas langsam, aber wo ist der Vorteil ggü Events?

LaTino

Ein Vorteil ist das Unsubscriben.
Hierfuer brauch man nur Subject.Dispose() aufrufen.

Kann mir vorstellen, dass es noch viele weitere gibt, da Rx noch einiges mehr kann.
Vielleicht wissen die ProCoder mehr. 😃

Rx bietet sozusagen Linq für Events.
Wenn Du sauber mit Events arbeitest, dann brauchst Du 3 Eventhandler *OnNext *OnError *OnCompleted

• in Rx ist das ein Observable, daß Du dann auch mit einem Statement statt 3 abarbeiten kannst.

Hm, hab mich wohl falsch ausgedrückt. Ich kenne Rx, ich sehe nur hier kein Problem, dass rx für ihn lösen würde, außer zusätzliche Komplexität einzuführen - deshalb meine Frage: wozu?

LaTino