Bei einer Webseite mit relativ hohen Zugriffszahlen wird man früher oder später gezwungen sein ein Caching zu implementieren und die HTML-Ausgabe für eine gewisse Zeit direkt auszuliefern, anstatt eine Seite jedes Mal neu zu erstellen. Gängiger Weg ist hier diese Ausgabe direkt als HTML mit einer gewissen Lebenszeit im Dateisystem abzulegen.

Nehmen wir nun mal ein Forum an. Eine Forenseite ist so lange gültig, bis ein neuer Eintrag kommt, ein Eintrag geändert wird oder eine Antwort erscheint.

Jetzt kann man natürlich das ganze von Hand zu Fuß fest im Code verdrahten und bei der Erstellung eines neuen Inhaltes alle zugehörigen Dateien direkt löschen. Das klappt ganz toll, bis sich die Struktur des Caches ändert, oder eine neue Art der Ausgabe der Inhalte hinzu kommt.

Sinnvoller ist es da, das Caching auszulagern, womit man vor dem Problem steht, wie der Cache erfährt dass etwas geändert wurde und gleichzeitig den Aufwand gering hält, also nicht pauschal alle Dateien im Cache löschen muss.

Hier bietet sich das Observer-Pattern an indem der Cache als Observer im Subject (den Beiträgen) registiert wird, denn nur der Cache weiß, was wo gecached wurde und wieviel gelöscht werden muss, wenn sich ein Inhalt ändert.

Im Gegensatz zur Möglichkeit die Cache-Änderung im Script, welches einen neuen Beitrag annimmt anzustoßen bietet das Observer-Pattern hier eine viel größere Flexibilität, da es die Einführung neuer Arten von Inhalte aus der Verarbeitung dieser heraus hält.

Was mir dabei aufgefallen ist was der Parameter “$notificationType” in der Funktion “notify” des Observers da zu suchen hat. Somit ist es dem Oberserver also möglich zu überprüfen von welcher Funktion er aufgerufen wurde.

Ich finde das verfehlt doch irgendwie den Zweck des Patterns und kommt doch dann eher dem EventDispatching näher, oder?

Ich würde es auch am liebsten so anwenden da ich genau vor so einen Problem stehe doch ich komm mir dabei so “dirty” vor als wenn ich das Pattern zum EventDipatching misshandeln würde.

Äh…man sucht nicht nach Anwendungen für Patterns, sondern nach Patterns, die ein konkretes Problem einer Anwendung lösen können.

Bsp:
Ich muss einen Nagel ins Holz schlagem – Ah, das Hammer Pattern!
vs.
Ich habe einen Hammer – was mach ich nu damit?

Und Singletons gelten, zumindest oder mindestens wenn man testgetrieben entwickelt, als Anti-Pattern. Und das nicht zu Unrecht. Ist wohl so populär, weil es einfach zu verstehen ist und das obige Hammer-Problem von hinten rum angeht.
Je komplexer die Dinge werden, desto mehr sieht man aber, dass das Pattern meist für die Katz ist und nicht wirklich hilft.

Cheers!

Ich persönlich finde derzeit jedoch keine Anwendung für dieses Entwurfsmuster, ich bin und bleibe Fan von Singleton

Spätestens, wenn das Hühnchen im Ofen ist, weiss es dass es so etwas gibt! ;D

In deinem Observer hast du übrigens einen Fehler. Dort rufst du die $chicken Methode getTemparature() auf, richtig wäre aber getInnerTemperature()