Ich finde ziemlich gefährlich dass ein Observer hier nicht weiß wo er sich angemeldet hat. Vielleicht ist das ja so gewollt und es gibt einen übergeordneten Manager der sich um so etwas kümmert, aber spontan würde mir fehlen dass sich ein Observer spätestens in seinem Destruktor überall wieder abmeldet wo er noch angemeldet ist. Sonst wird dein Subject bei der nächsten Aktualisierung versuchen eine tote Instanz zu benachrichtigen.
Kleinigkeiten:- Der Typname TObservers (Plural) ist Quark
- Man sollte vielleicht überlegen ob man TObservers.Update()
nicht gleich virtual abstract
macht oder - Hey, noch besser: Die Leute nicht zwingt seine Klasse von TObserver
abzuleiten sondern es gleich über ein Interface macht das man implementieren kann (Java-Observable lässt grüßen)
Ganz allgemein:
Das liest sich insgesamt irgendwie wie das typische Java Observer Pattern vor Java 8. In Sprachen die anonyme Methoden/Funktionszeiger schon länger haben (z.B. Delphi, C++, C#, …) hätte ich die Subjects überhaupt nicht mehr an eine Observer-Klasse/Interface gebunden sondern einfach nur eine Collection an Events/Funktionszeigern gegeben die bitte ausgeführt werden wenn sich z.B. durch
setState(..)
der Zustand ändert.
Du sagst
Zitat:
Verstehe das Konzept des Beobachter Muster noch nicht ganz.
- Was fehlt denn genau? Ein praktischer Anwendungsfall? Eine Umsetzung mit einem Delphi-Formular wo man auch ganz konkret mal etwas zu gucken hat (das finde ich immer motivierend).