[Ben]

Hallo,
ich habe eine Frage zu den Anwendungsbereichen des Observer-Patterns in PHP.
Ich beschäftige mich gerade etwas intensiver mit dem Model-View-Controller in PHP, also wie dieses Muster in PHP am besten umgesetzt wird.

Ich habe bislang nur ansatzweise in Java damit gearbeitet, so dass ich mich zumeist auf dieses Beispiel und die dazugehörige Erläuterung bezogen habe:
http://www.java-forum.org/de/viewtopic.php?t=6090#52829

Dort ist die Struktur folgendermaßen:

Model

-----

View implements Observer

-----

Controller implements Observable

Demnach habe ich mir wie gesagt mal das Observer-Pattern für PHP angeschaut, sehe aber gerade nicht wirklich, wo ich das im Produktiveinsatz gebrauchen könnte.

Sagen wir, ich habe eine Anwendung, die sich auf das MVC-Pattern stützen will.
An welcher Stelle kommt denn dort das Observer-Pattern zum Einsatz?

In obigem Link ist ja ein Beispiel dargestellt, aber irgendwie scheine ich nicht in der Lage zu sein den Transfer auf z.B. ein Content-Management-System o.Ä. durchzuführen.

Ich wäre erfreut Eure Erfahrungen mit den Mustern (MVC, Observer) im Produktiveinsatz kennenzulernen und Informationen über die Anwendungsbereiche zu erhalten.

Ich danke Euch im Voraus.
Grüße, Ben.

[Ben]

Eine Lektüre für das Wochenende!
http://www.tonymarston.net/php-mysql...ontroller.html

Nicht ganz einfach, aber sehr interessant. Lese jetzt ca. 40 Minuten und ich finde es sehr gut geschrieben.
Auf jeden Fall lohnenswert!

Grüße, Ben.

Das ganze funktioniert grundsätzlich so:

Du hast eine Observerable Klasse und eine Observer Klasse.

Jedes Objekt das von der Observer Klasse erbt wird in dem dem Konstruktor übergebenen Observerable Objekt in einem Array als Referenz gespeichert.

Die notifyOberservers Methode der Observerable Klasse ruft automatisch für jedes Obeserver Objekt eine update Methode auf. Diese update Methode führt eben irgendetwas aus, z.B. Daten in der DB updaten oder sonst was.

Ich habe jetzt auch gleich mal eine kleines Beispiel zusammengetippt, damit es leichter zu verstehen ist. Hoffe ich zumindest .

Beispiel:

PHP-Code:

<?php
class Observerable
{
    private $observers = array ();
    private $state;
    
    public function addObserver (Observer $observer)
    {
        $this->observers[] = $observer;
    }
    
    public function notifyObservers ()
    {
        foreach ($this->observers as $observer)
        {
            $observer->update ();
        }
    }
    
    
    public function getState ()
    {
        return $this->state;
    }
    
    public function setState ($state)
    {
        $this->state = $state;
    }
}

class Observer
{
    private $subject;
    
    public function __construct (Observerable $subject)
    {
        $this->subject = $subject;
        
        $subject->addObserver ($this);
    }
}

class Observerable_A extends Observerable 
{
    public function doSth ()
    {
        $this->setState ("The current state");
        $this->notifyObservers();
    }
}

class Observer_B extends Observer 
{
    public function __construct (Observerable $subject)
    {
        parent::__construct ($subject);
    }
    
    public function update ()
    {
        echo "update function ob class B called\n";
    }
}

class Observer_C extends Observer 
{
    public function __construct ($subject)
    {
        parent::__construct ($subject);
    }
    
    public function update ()
    {
        echo "update function ob class C called\n";
    }
}

$observerable = new Observerable_A ();

$observer_B = new Observer_B ($observerable);
$observer_C = new Observer_C ($observerable);

$observerable->doSth ();
?>

Wenn man dieses Script ausführt so wird folgendes ausgegeben:

update function ob class B called
update function ob class C called

Durch den state des Observerable Objekts kann in der Update Methode der Oberserver Objekte je nach status unterschiedlich reagiert werden.

MfG Jay

[Ben]

Nett, dass du geantwortest hast, aber meine Frage eigentlich eher, an welcher Stelle ich das anwende.
Das, was du mir da jetzt beschrieben hast steht eigentlich genauso in oben verlinktem Artikel bei phppatterns.com.

Kannst du mir eventuell ein weiteres Anwendungsbeispiel geben?
Das obige .. nunja, wie gesagt .. ich schaff einfach nicht den Transfer.

Hmm ... mir fällt jetzt dazu eigentlich kein Praxisbeispiel ein.

Du musst dir halt immer nur folgendest merken:

1. Verwaltet 1:n Relationen zwischen Objekten
2. Wird meistens dazu eingesetzt, um die Synchronität zwischen Objekten zu wahren.
3. Bei Veränderungen im Observerable Objekt, reagieren alle Observer automatisch

Bei der Event-driven Programmierung ist es sehr sinnvoll sowas einzusetzen.
Dritt ein Event auf, so werden für alle anderen Objekte eben automatisch die update Methoden aufgerufen.

Hoffe ich hab dir etwas geholfen.

Mfg Jay

[Ben]

Jou, das Prinzip hatte ich verstanden (hast du aber trotzdem gut dargestellt! -).

Ich habe darüber nachgedacht, wie man dieses Observer-Muster in ein "MVC-System" integrieren könnte und vor allem, an welchen Stellen dies sinnvoll wäre.
Ich habe irgendwie im Hinterkopf, dass ich mit diesem Entwurfsmuster eine Aktion des Users realisieren und darauf reagieren kann.
Dies ist ja auch bei phppatterns.com so dargestellt.

Es wird ein Beitrag in einem Forum geschrieben und daraufhin wird eine Mail an alle User geschickt, die sich informieren lassen wollen, wenn eine neue Nachricht geschrieben wurde.
Das ist ein gutes Beispiel .. aber es kann ja nicht das einzig sinnvolle sein, oder?

Die Frage richtet sich natürlich nicht nur an Jay, sondern an alle, die das hier lesen.
Ich werde jetzt erstmal aufhören darüber nachzudenken. Ist schon spät.

Freue mich aber über weitere Beiträge von Euch.

Grüße, Ben.

[pago]

Ähm... ganz kurz und knapp: Nein, nein, nein und nochmals nein!

Das Observer-Pattern dient dazu, ein anderes Objekt zu beobachten - im speziellen auf Änderungen. Nun überlege doch mal, welche Objekte sich zu beobachten lohnen und durch wen.

Um's kurz zu machen: Das View muss definitiv nicht beobachtet werden (weder vom Model noch vom Controller). Der Controller ist dafür verantwortlich, Model und View zusammen zu bringen, also macht es ebenfalls keinen Sinn, dass zu beobachten.
Bleibt nur noch das Model übrig und siehe da: Das stimmt.

View (Observer) observiert Model (Observable).


Ein Beispiel kann ich dir jetzt so spontan nicht liefern, weil ich nicht sehen kann, wo das in einer Webseite Sinn machen soll - auch das Beispiel auf phpPatterns ist extrem dünn. Da wäre ein globaler EventBus sinnvoller gewesen, aber gut...

Generell solltest du dir aber folgendes merken: Es ist _nicht_ gut, Design Patterns zu verwenden. Design Patterns bedeuten _immer_ zusätzliche Komplexität. Deshalb solltest du nicht versuchen, die irgendwo zu verwenden, sondern sie nur dann einsetzen, wenn sie wirklich notwendig sind. In deinem Fall klingt es so, als ob du unbedingt irgendwo ein Observer-Pattern einbauen willst, ob das nun notwendig ist oder nicht.

Um's auf den Punkt zu bringen: Observer-Pattern == EventListener in Java

[Ben]

Zitat von pago

In deinem Fall klingt es so, als ob du unbedingt irgendwo ein Observer-Pattern einbauen willst, ob das nun notwendig ist oder nicht.

Faktisch frage ich nur nach Anwendungsbereichen, um mir dann meine eigene Meinung über Sinn und Unsinn bilden zu können.

Man lese

Zitat von Ben

Ich wäre erfreut Eure Erfahrungen mit den Mustern (MVC, Observer) im Produktiveinsatz kennenzulernen und Informationen über die Anwendungsbereiche zu erhalten.

Deshalb: Danke.

Genau sowas in der Art, wie du es jetzt geschrieben hast will ich ja hören.

Was meinst du mit "EventBus"?

[pago]

Beim malen viel mir auf, dass es auf funktionieren würde (bei diesem Beispiel), wenn den EventBus weglassen würde und stattdessen direkt den PostManager zum Observable machen würde.
EventBus hat den Vorteil, dass statt one-to-many Beziehungen (ein Observable, viele Observer) auch many-to-many Beziehungen (mehrere Observable, mehrere Observer) möglich sind und die Observer nicht wissen müssen, wen sie da eigentlich observieren. d.h. es entstehen weniger hard-codierte Beziehungen und das ganze bleibt deutlich dynamischer.

[Ben]

Joa, so wirklich habe ich die Grafik jetzt ja nicht verstanden

[pago]

Ok... dann etwas Code dazu:

PHP-Code:

<?php
/*
 * Ich überspringe die Definition der meisten Klassen, die hast du ja schon als UML gesehen
 */

class FeedUpdater implements EventListener {
    public function handleEvent(Event $event) {
        echo "FeedUpdater aufgerufen.\n";
    }
} // PostMailer analog

class PostManager {
    public static function createPost(Post $post) {
        $event = new PostEvent(PostEvent::CREATED, $post);
        EventBus::fireEvent($event);
    }
    
    // ...
}

class PostEvent {
    const CREATED = 1;
    // andere Konstanten
    
    public function getTopic() {
        return "post";
    }
}

// das sollte im Idealfall über einen ServiceLocator realisiert werden, um unnötige initialisierungen zu vermeiden
EventBus::addEventListener("post", new FeedUpdater());
EventBus::addEventListener("post", new PostMailer());
 
$post = new Post("Ein Beispiel", "Ok, das hier ist also ein Beispiel.");
PostManager::createPost($post);

/*
 * Ausgabe:
 * FeedUpdater aufgerufen.
 * PostMailer aufgerufen.
 */
?>

Jetzt besser?

[Ben]

Ahso. Ja, ist besser.

Dein Beispiel gefällt mir. Lässt sich ja als Alternative sehen. Warum genau würdest du jetzt aber sagen, dass deine Variante vorteilhafter ist?
Du sprichst ja davon, dass ich durch Entwurfsmuster die Komplexität erhöhe (was imho bei strukturierter Anwendung nicht unbedingt was Schlimmes sein muss!). Dein Beispiel ist aber nun ja nicht weniger komplex bzw. in diesen Fällen finde ich beide Beispiele eher simpel.


Dann noch etwas zu deinem Beispielquelltext.
Es müsste doch heißen "PostEvent implements/extends Event" oder?
Weiterhin weiß ich nicht so ganz, was du in der UML-Grafik mit "sourcebject" bei der Klasse Event meinst.

Weiterhin

Zitat von pago

das sollte im Idealfall über einen ServiceLocator realisiert werden, um unnötige initialisierungen zu vermeiden

Bekomm ich da auch noch eine kurze Erklärung zu?

Danke dir.

Grüße, Ben.

[Ben]

Soderle.
Ich habe noch einige weitere Fragen zu deinem Quellcode.
Einige Punkte sind mir nicht klar, weil ich teilweise irgendwie keinen Anwendungsfall für sie habe ...

1. Wozu sind die Konstanten der Klasse PostEvent gut? Generell habe ich mit dieser ganzen Klasse Probleme .. was genau macht die?
   
   PHP-Code:

   class PostEvent {
    const CREATED = 1;
    // andere Konstanten
    
    public function getTopic() {
        return "post";
    }
} 

2. Ist das, was du hier dargestellt hast, eine andere Ansicht des MVC-Prinzips? (Nein, ich will es nicht um jeden Preis anwenden, ich will das einfach nur verstehen!)
3. Warum ist die createPost()-Methode der Klasse PostManager statisch?
   Ich hätte hier mit einem Singleton gearbeitet. Danke!
4. In den Methoden der Klasse PostManager würde dann z.B. auch auf die Datenbank zugegriffen etc.! Stimmt das? Oder wird dieser Zugriff in den Klassen realisiert, die EventListener implementieren?

Ich wollte das von dir skizzierte Prinzip (welches mir recht gut gefällt) gerne auf ein minimales Newssystem übertragen. Dabei kam es zu obigen Fragestellungen.

Ich freue mich auf Beantwortung.
Grüße, Ben.

[pago]

Den Code hatte ich in ein ner Minute zusammengewürfelt, weil ich weg musste.

Warum genau würdest du jetzt aber sagen, dass deine Variante vorteilhafter ist?

Wir vergleichen ja noch mit dem Observer, richtig? Die alternative wäre hier also, dass sich die Listener direkt im PostManager-Objekt als Observer anhängen. Nun kann es aber unter Umständen (vielleicht nicht in diesem Beispiel, generell aber in komplexeren) vorkommen, dass du noch eine weitere Klasse hast, die posts hinzufügt. Und zwar nicht über den PostManager.
Wenn die Listener dann immer noch agieren sollen, dann hast du das Problem, dass du die alle auch noch bei diesem neuen Code registrieren musst. Bei meiner Variante ist dieser Fall bereits abgedeckt - der Code ist also flexibler.
(1 zu n gegen n zu m)

Dein Beispiel ist aber nun ja nicht weniger komplex bzw. in diesen Fällen finde ich beide Beispiele eher simpel.

Deshalb gilt abzuwägen, welche der Lösungen das beste Verhältnis zwischen Kosten und Nutzen hat. Ein weiterer Vorteil eines solchen EventBus-Systems ist meiner Meinung nach, dass du das in der ganzen Anwendung verwenden kannst. Bei einem normalen Observer-Pattern muss man jedesmal die API des Observable kennen (eine einfache "notify"-Botschaft reicht nie im Leben aus - das ist völlig unnütz, d.h. eine komplexere Observable-Struktur wie in Java ("addPropertyChangeListener()", "addActionListener") ist auf jedenfall nötig).

Es müsste doch heißen "PostEvent implements/extends Event" oder?

Ja, müsste es. (PostEvent extends Event)

Weiterhin weiß ich nicht so ganz, was du in der UML-Grafik mit "sourcebject" bei der Klasse Event meinst.

"source" ist da "objekt", dass für das Ereignis zuständig war. Im Beispiel oben könnte man über die Event#getSource()-Methode auf das "Post"-Objekt zugreifen, dass für das Event wichtig ist. Da kommt dann das hier ins Spiel:

Wozu sind die Konstanten der Klasse PostEvent gut?

Sie sagen den Listenern, was genau passiert ist. Wurde ein Post hinzugefügt? Gelöscht? Bearbeitet?

Generell habe ich mit dieser ganzen Klasse Probleme .. was genau macht die?

Prinzipiell verfügt diese Klasse einfach nur über Informationen über das aktuelle Ereignis. "Wer hat das Ereignis ausgelöst? Was ist passiert? etc."

Ist das, was du hier dargestellt hast, eine andere Ansicht des MVC-Prinzips?

Wenn ich das, was ich dir oben als Observer-Ersatz vorgeschlagen habe, in MVC einordnen sollte, dann wäre es wahrscheinlich die Schicht, die Model, View und Controller verknüpft.
Im oberen Beispiel würde eine Änderung des Models (PostManager und Post) über die Datenschicht (EventBus) an ein paar Controller (PostMailer, FeedUpdater) weiterleiten, die dann ein neues View erzeugen würden.

Das ist so ziemlich das sinnvollste, was ich mir unter Observer und Web-Applikationen vorstellen kann.
Der Ursprung des Observer-Patterns ist ja doch etwas anders: Ein Controller ändert das Model, dass Model benachrichtigt die Observer, die "zufällig" dem View entsprechen. Eine solche Änderung kann aber bei PHP-Scripts gar nicht erst stattfinden, weil Daten nicht wirklich persistent sind. Es wird kein Zustand gespeichert. Posts werden ausgelesen, geändert und neu erstellt. Aber dafür werden jedesmal neue Posts erzeugt. Deshalb macht das normale Observer-Pattern keinen Sinn. Ein Datenobjekt in PHP ist nicht mehr als eine Klasse mit Attributen und Business-Logic, aber sie muss eben nicht observiert werden.

Warum ist die createPost()-Methode der Klasse PostManager statisch?
Ich hätte hier mit einem Singleton gearbeitet.

PostManager darf/sollte ein Singleton sein, ja.

(ServiceLocator)

Bekomm ich da auch noch eine kurze Erklärung zu?

Kurz? Ähm ja... in dem Beispiel sind die Verknüpfungen zwischen EventListener und EventBus fest im Code. Weil das ganze eine Web-Applikation wird, die wahrscheinlich auch nicht mit Plugins arbeiten muss, ist das allerdings kein großes Problem. In dem Fall würde es schon reichen, wenn die Listener nur dann erzeugt werden, wenn sie benötigt werden (lazy initialization). Aber ich persönlich hab es ganz gerne, wenn ich soetwas schreiben kann:

PHP-Code:

<?php
$eventListeners = ServiceLocator::getInstance()->getAllServices("post");
?>

Und der Code würde dann alle Listener erzeugen, die auf Ereignisse des "post" Topics reagieren. Wo genau der die herholt ist dabei irrelevant. Meinetwegen einer XML-Konfigurationsdatei, wenn es denn sein muss. Alternativ wird einfach nur ne PHP-Datei namens "post.services.php" inkludiert:

PHP-Code:

<?php
$services[] = new PostMailer();
$services[] = new FeedUpdater();
?>

Es geht also darum, dass man das lokalisieren von "Services" verstecken will. Ein Pattern, dass ich in SimpleEdit extrem häufig einsetze. Auf PHP übertragen macht es aber in diesem Fall hauptsächlich wegen der Vermeidung der Erzeugung von unnötigen Listenern Sinn. *puh*

Kurz genug?

[Ben]

Muss ich erstmal sacken lassen und verstehen, was du alles so gesagt hast.
Hat mir aber auf jeden Fall schon nach zwei Mal lesen geholfen.

*les*