Mittlerweile habe ich etwa 30 Einladungen verschickt und auch wirklich jeder, der an einem Konto interessiert war, sollte mittlerweile ein Konto sein Eigen nennen. Allerdings ist bei mir die Euphorie abgeflaut. Keiner meiner bekannten nutzt mehr Google Wave. Wie konnte es dazu kommen?

Die Tatsache, dass viele Bekannte anfangs keinen Nutzeraccout hatten, minderte den “Entdeckungsfaktor”, wie ihn etwa Facebook mit sich bringt. Zudem ist Google Wave deutlich zu komplex. Nicht im Sinne von schlechter Usability o.ä., aber die Möglichkeiten überfordern normale Benutzer einfach. Z.b. würde ich meiner Mutter nie beibringen können, eine Wave zu verfassen; Zu Komplex ist das Konzept der Applets in Waves  für Nicht-Entwickler.

Tja, und so kam mir heute nach ewigen Tagen Abstinenz zur Plattform mal wieder in den Sinn, einen Blick hinein zu werfen. Mit dem erwarteten Ergebnis: Seit Monaten tut sich NICHTs. Keine neuen Waves, keine neuen Kontakte, kein neuer Spaß.

Google Wave ist für mich das beste Beispiel, wie man ein Produkt durch Overhyping töten kann.

Wie üblich verhindert es das knappe viertelstündige Zeitkorsett des Web Montags allzusehr in die Tiefe zu gehen. Dennoch ist der Vortrag sicher ein interessanter Überblick und ein schneller Einstieg in die Materie. Ich wünsche Euch viel Spaß beim Ansehen und freue mich auf Kritik!

Die richtigen Keywords sind das A und O
Am Anfang aller Optimierungen steht die Entscheidung, für welche Schlüsselbegriffe (Keywords) man seine Seite optimieren möchte. Hier bieten sich natürlich die Tätigkeitsfelder des Unternehmens an, jedoch sollte man auch nach Wortfamilien recherchieren! Begriffe wie "Performance-Marketing" oder "Mobile-Marketing" können treffende Fachbegriffe sein, aber sucht ein potenzieller Interessent auch danach? Sind Begrifflichkeiten wie "Erfolgskontrolle" und "Handy-Marketing" als Suchbegriffe nicht ebenso wahrscheinlich? Die richtige Mischung aus Fachbegriffen und umgangssprachlichen Begrifflichkeiten spricht ein breiteres Zielpublikum an.
Die ausgewählten Begriffe gilt es nun möglichst geschickt in die Texte der Website zu integrieren. Hierbei stellt es sich als weitaus erfolgreicher heraus, einzelne Seiten auf bestimmte Themengebiete hin zu optimieren, als alle Themen auf eine Seite packen zu wollen. Die Spezialisierung bringt wertvolle Punkte in den Bewertungskriterien der Suchmaschinen.
Die Positionierung der Keywords in den Meta-Tags der Seite galt früher als sicherer Garant dafür, dass diese Begriffe von den Suchmaschinen verstärkt wahrgenommen werden. Der Missbrauch der Meta-Tags in der Vergangenheit, vor allem durch die Pornoindustrie (kennen Sie noch die Zeiten, in denen zwielichtige Angebote stets zu den ersten Suchergebnissen gehörten, unabhängig davon wonach Sie gesucht haben?) hat dazu geführt, dass der Einfluss der Meta-Tags auf die Bewertung stark abgenommen hat.

Bewertungskriterien im Wandel
Und hierbei sind die Meta-Tags nur die Spitze des Eisbergs. Der ständige Wettlauf zwischen Bewertungskriterien und deren Missbrauch hat dazu geführt, dass die großen Suchmaschinen ihre Bewertungskriterien ständig überarbeiten und anpassen. Insofern ist Suchmaschinenoptimierung ein ständiger Vorgang, der nie abgeschlossen ist. In gewissen Intervallen sind die Kriterien, welche man an die Seite angelegt hat, kritisch zu beleuchten, und die daraus gewonnenen Erkenntnisse in eventuelle Optimierungen einfließen zu lassen.

Techniken zur Optimierung
Natürlich gibt es eine große Anzahl technischer Ansätze, um eine Seite für Suchmaschinen attraktiv zu gestalten. Hierbei unterscheidet man zwischen den so genannten On-Page- und Off-Page-Faktoren. Als On-Page bezeichnet man die Faktoren, welche auf einer Seite die Platzierung in Suchmaschinen bestimmen, etwa Content und Quelltext. Die Off-Page-Faktoren hingegen beziehen sich auf Wertungskriterien außerhalb der eigenen Website, etwa Verlinkungen von anderen Websites und deren qualitative Bewertung.
Allen Kriterien voran stehen XHTML/CSS-konforme Layouts. Der Grund hierfür ist recht einfach: Google kann nur das gut bewerten, was es auch versteht. Komplizierte Tabellenlayouts lassen korrespondierende Inhalte vielleicht optisch beieinander stehen, im Quellcode liegen sie meist mehrere hundert Zeilen Code auseinander. Nun betrachtet Google allerdings nicht das Erscheinungsbild, sondern liest den Quellcode. Und da sorgen knappgehaltene XHTML-Auszeichnungen dafür, dass im Quellcode zusammensteht, was zusammengehört. Zusätzlich kann man es so einrichten, dass oben in der Datei die relavanten Inhalte auftauchen und nicht zwingend das, was optisch oben auf der Seite angezeigt wird. Zwingend muss darauf geachtet werden, dass das produzierte XHTML wirklich valide ist. Im schlimmsten Fall kann der Seitenparser der Suchmaschine die Seite nicht korrekt auswerten oder greift sich belanglose Inhalte.
Überhaupt kann man mit ein wenig Wissen relativ gut steuern, welche Inhalte die Suchmaschine als relevant erachtet, um diese in die Gewichtung mit einzubeziehen oder in ihren Ergebnislisten als Textausschnitt anzuzeigen. Der Schlüssel dafür liegt in den altehrwürdigen Title- und Headline-Tags. Wichtig ist vor allem der Title-Tag: Dieser beschreibt, worum es auf der Seite geht. Ist dieser leer oder auf jeder Seite gleich, kann dies nicht optimal sein. Besser ist es, die relevante Seitenüberschrift auch in den Title-Tag zu packen.
Wenn wir schon bei den Title-Tags sind: Natürlich sollten auch die Title- und Alternative-Tags von Bildern stets gefüllt werden, um Suchmaschinen das zu beschreiben, was sie nicht mit eigenen Augen auf den Bildern sehen können.
Neben dem Title-Tag sollte die Seitenüberschrift natürlich im Headline-Tag (h1, h2, …) stecken. Schon vom W3 Consortium ersonnen, um Überschriften unterschiedlicher Gewichtung abzubilden, sollten die Tags auch genau hierzu eingesetzt werden. Die Hauptüberschrift sollte immer h1 sein, danach folgen die unwichtigeren Überschriften mit aufsteigenden hs. Eine richtige Schachtelung erreicht man dadurch, dass nach einer h1 eine h2 und danach eine h3 folgt. Nach der h3 kann wieder eine h2 und dann wieder eine h3 folgen, womit festgelegt wäre: Die erste h3 ist eine Untergliederung von h2, die zweite h3 eine Untergliederung von der zweiten h2, die textlich nicht mit der ersten h2 korreliert. Möchte man nun wichtige Keywords kombinieren, packt man optimalerweise das erste Keyword in eine Überschrift und das zweite Keyword in die erste Zeile des Fließtexts unterhalb der Überschrift.
Ebenfalls hat es sich als effektiv erwiesen, die Keywords auf einer Seite zu verlinken: Bietet eine Webagentur SEO an, so sollte dies nicht nur im Menü als "Suchmaschinenoptimierung" aufgeführt werden, sondern auch den Begriff "SEO" überall auf der Website mit der Detailseite zu SEO zu verlinken.
Aber auch außerhalb des Content-Bereichs kann man zahlreiche Optimierungen vornehmen. Ein Ansatz ist die so genannten "sprechenden URLs" (URL-Rewriting), um Keywords möglichst prominent in der URL zu platzieren. Hierbei erzeugt man aussagekräftige URLs, die allerdings keine Aussage über die tatsächliche Platzierung der Dateien auf dem Webserver tätigen (etwa: www.shop.com/books/coding/php/). Der Webserver oder die Applikationslogik parsen die virtuellen URLs und liefern die assoziierten Inhalte aus.
Überhaupt sind ewig lange URLs den Suchmaschinen ein Graus. Denn meist machen URLs (wenn es sich nicht gerade um hässliche Parameter wie Session-ID handelt) eine Aussage über die Strukturtiefe der Website. Hier sind ganz klar flache Hierarchien anzuraten. Möglichst viele Inhalte sollten – natürlich nur, sofern dies wirklich sinnvoll ist – direkt von der Startseite aus erreichbar sein. Je kürzer der Klickpfad von der Startseite zur Unterseite ist, desto relevanter empfindet Google den Inhalt der Unterseite.
Möchte man ganz sicher gehen, dass Google auch ja keine der sorgsam erstellten Unterseiten übersieht, kann man spezielle XML-Sitemaps anlegen. Diese sind, ebenso wie robots.txt-Dateien, lediglich für die Crawler der Suchmaschinen gedacht und übergeben diesen eine komplette Liste aller vorhandenen Unterseiten. Somit werden auch Pop-ups indiziert, welche sich eventuell nur durch JavaScript öffnen lassen.
Generell wird ein Verzicht auf JavaScript und Flash von Suchmaschinen gern gesehen, falls nicht aufwändig für barrierefreie Ersatzinhalte gesorgt wurde. Es sei auch erwähnt, dass die Verlinkung von anderen Websites aus eine wichtige Rolle spielt. Natürlich gibt es auch hier zahlreiche Fallstricke bzw. Anforderungen, welche an die Partner-Website gestellt werden. Etwa die Themen-Verwandtschaft, Authority-Gewichtung (manche Websites sind bei bestimmten Stichworten kompetenter als andere), PageRank (Kombination verschiedenster Kriterien) und andere Besonderheiten. Ein gut gemeinter Ratschlag: Lassen Sie sich von einem Fachmann Ihres Vertrauens beraten, denn mit unkundigen Anpassungen kann man viel zerstören. Im schlimmsten Fall fliegen Sie für alle Zeiten aus den Suchergebnissen der Suchmaschinen.

Schwarze Schafe
"Fachmann Ihres Vertrauens" ist schön gesagt! Denn tatsächlich tummeln sich am Markt der Suchmaschinenoptimierer auch zahlreiche schwarze Schafe. Diese versprechen Ihnen bestimmte Platzierungen bei bestimmten Stichworten. Hier gilt: Niemand kann Ihnen eine konkrete Platzierung versprechen! Diese kann, wenn überhaupt, nur mit unseriösen und gefährlichen Tricks erreicht werden, womit wir wieder bei den sich ständig ändernden Kriterien wären. Denn sollte eine Suchmaschine plötzlich entscheiden, dass die bei Ihnen eingesetzten Tricks als "Suchmaschinen-Spam" oder "Suchmaschinen-Spoofing" zu verstehen sind, so können Sie von einem auf den anderen Tag aus dem Suchindex geworfen werden. Und dies ohne Benachrichtigung!
Solche "unseriösen Tricks" gibt es viele. So kann man Seiten bei dem Besuch eines Suchroboters für diesen anders darstellen als ein Besucher die Seite zu sehen bekäme. Auch sieht man oft versteckte Links auf Keyword-Seiten oder Texte, die für Besucher unsichtbar sind. Weißer Text auf weißem Hintergrund mag zwar für das Auge unsichtbar sein, nicht aber für die Suchmaschinen. Diese jedoch prüfen mittlerweile auch den HTML-Code dahingehend, ob der Text sichtbar wäre. Trickserien können an dieser Stelle für Sie schnell unangenehme Folgen haben.
Seriöse Anbieter erkennen Sie daran, dass diese Ihnen keine konkreten Platzierungen versprechen und mit Ihnen offen auf die Vor- und Nachteile der einzelnen Optimierungsmaßnahmen eingehen.

Schatz, wie war ich? Die Erfolgskontrolle
Ob Ihre Optimierungsmaßnahmen nun greifen, ist natürlich von entscheidender Bedeutung. Die Kontrolle des Besucherstroms über Webstatistk-Software wie Webalizer bringt Ihnen nur wenig Erkenntnis. Zwar können Sie ersehen, ob die Besuchsfrequenz zu- oder abnimmt, aber der Grund dafür bleibt Ihnen meist verborgen.
Moderne WebAnalytics-Tools sind mächtige Werkzeuge, die das Thema Erfolgskontrolle in seiner Gänze abbilden. Sie beginnen bei der Bewertung der Keywords (Suchhäufigkeit und Tefferanzahl), gehen über Suchbegriffe, unter welchen Ihre Seite gefunden wurde, hin zu den damit angelockten Besuchern und deren Surfverhalten und hört bei der Messung eventueller Conversions noch lange nicht auf.
Der Markt dieser Werkzeuge ist in den letzten Jahren signifikant gewachsen. So findet sich für jedes Portemonnaie mittlerweile die passende Lösung. Doch zumindest für essenzielle Auswertungen muss man kein Geld ausgeben: Mit GoogleAnalytics hat Google ein Produkt auf den Markt gebracht, welches für Seiten mit mittlerem Besuchsaufkommen kostenlos ist.

Fazit
Suchmaschinen-Optimierung ist ein komplexes Thema. Trotz der Erkenntnis, die Sie nach der Lektüre des Artikels sicher mit mir teilen, gibt es viele Ansätze, welche Sie mit geringem Aufwand oder ohne großes Budget verwirklichen können. Dennoch ist die Optimierung nie abgeschlossen und sollte immer wieder aufs Neue überdacht und überprüft werden. Aber mit dieser Einsicht sind Sie bereits auf einem guten Weg, Ihre Seite für Suchmaschinen freundlicher zu gestalten.

Ausblick: Das semantische Web
Derzeit ist das semantische Web (gerne auch als Web 3.0 bezeichnet) in aller Munde. Hinter der Bezeichnung verbirgt sich, ähnlich wie schon beim Web 2.0, nicht eine konkrete Entwicklung, sondern in diesem Falle das Zusammenspiel mehrerer Technologien (XML, XML Schema, RDF, OWL, SPARQL). Im semantischen Web wird durch bessere Auszeichnung der Inhalte deren Verstehen für die Wiedergabe-Programme (Browser, Newsreader, Web Services etc.) ermöglicht. Die Programme haben somit die Möglichkeit, die Inhalte entsprechend ihrer Bedeutung aufzubereiten, thematisch zu ordnen oder nach bestimmten Kriterien zu gliedern.
Dies hat große Relevanz für die Suchmaschinenoptimierung, da über entsprechend gekennzeichnete Inhalte den Suchmaschinen sehr gezielt der enthaltene Sinn vermittelt werden kann. Bieten Sie zum Beispiel in einem Webshop das Buch "Die Wolke" an, fördern Suchanfragen nach "Wolke" in einer Suchmaschine das Produkt nur dann zu Tage, wenn dort auch explizit nach Produkten gesucht wurde.

SEO !== SEM
Häufig werden die Begriffe SEO (search engine optimization) und SEM (search engine marketing) durcheinander geworfen. SEO bezeichnet die in diesem Artikel beschriebene Suchmaschinenoptimierung, während man unter SEM bezahlte Werbeeinblendungen in Suchmaschinen versteht. Bisweilen wird SEO auch als eine Untermenge von SEM verstanden. Dieser Interpretation kann ich mich aber nicht anschließen.

Problemlösung
Der Ansatz, den das Beobachter-Entwurfsmuster (eng.: observer pattern) beschreibt, definiert Abhängigkeiten zwischen Objekten in einem publisher/subscriber genannten Verfahren: Objekte, welche von bestimmten Objekten abhängig sind, „abonnieren“ diese und werden von ihnen fortan über Änderungen des abonnierten Objektes unterrichtet.
Damit zählt das Beobachter-Muster zu der Klasse der objektorientierten Verhaltensmustern indem es Abhängigkeiten zwischen Objekten abbilden kann.
Dies geschieht wie folgt: Zu einem bestimmten Zeitpunkt erbittet der subscriber ein Abonnement beim publisher. Dies geschieht am sinnvollsten bereits im Konstruktor des subscribers. Hierzu muss der subscriber dem publisher eine callback Schnittstelle anbieten, über die der publisher ihn erreichen kann. Der publisher wiederum führt alle seine Abonnenten in einer Abonnentenliste. Ändert sich nun der Zustand des publishers so, dass sich dies auf seine äußere Repräsentation niederschlägt, so informiert er alle in der Liste enthaltenen Abonnenten über deren einheitliche Schnittstelle.
Das Schlagwort der äußeren Repräsentation ist schnell erklärt: Zustandsänderungen können entweder private Attribute betreffen, die nach außen hin nicht sichtbar sind und auch keine Rückgabewerte von öffentlichen Methoden verändern, oder sie können öffentliche Attribute und Rückgabewerte von öffentlichen Methoden ändern. Zustandsänderungen der zweiten Art verändern somit die äußere Repräsentation der Objekte; In der Regel sind nur sie interessant für Abonnenten.
Es obliegt nun dem subscriber auf die vom publisher mitgeteilte Änderung zu bearbeiten. Hierzu muss der subscriber ermitteln, ob die Änderungen des publishers für ihn relevant sind und entsprechend reagieren: Entweder die Änderung ist relevant und der subscriber fragt benötigte Attribute des publishers ab, oder er ignoriert die Mitteilung. In einer anderen Variante dieses Enturfsmusters sendet der publisher Informationen über die erfolgten Änderungen gleich mit (siehe hierzu Box „Push or pull?“).
Ein so bestehendes publisher/subscriber Verhältnis lässt sich natürlich jederzeit (auch ohne Beachtung von Fristen und Vertragslaufzeiten) kündigen; Der publisher streicht den subscriber auf dessen Anfrage hin einfach aus seiner Abonnentenliste. Der subscriber erhält darauf hin keine Mitteilungen mehr vom publisher.
Das ganze Verfahren ist so bildlich, dass es quasi selbsterklärend ist. Aus diesem Grunde wird dieses Mal auf ein Beispiel aus dem wirklichen Leben verzichtet.

Implementierung
Nachdem im Juli der final release von PHP5 veröffentlicht wurde, macht dieses Beispiel Gebrauch von dessen neuen objektorientierten Features und Sprachkonstrukten. Gerade die Einführung von Interfaces erweist sich als hilfreich: Da das Beobachter-Muster unabhängig von den Klassentypen der involvierten Objekte funktionieren sollte, unterstützen Interfaces den Gedanken der losen Kopplung von Objekten: Die Objekte sind konsequent austauschbar solange deren (teilweise) durch Interfaces definierte API gleich bleibt. Aber auch an Leser, die aus unterschiedlichsten Gründen auf PHP4 festgelegt sind, wurde gedacht: Die Box „Das Beobachter-Muster in PHP4“ gibt einige Anregungen zur Portierung des vorliegenden Quellcodes nach PHP4.
Die Vorüberlegung über die Gestaltung der API schlägt sich in der Implementierung von Interfaces nieder: Diese bestimmen alle Methoden und deren Signaturen, über welche die Kommunikation zwischen den am subscriber/publisher Verfahren beteiligten Objekten später abläuft (Listing 1).
Das publisher Interface definiert die API zum Abonnieren bzw. zum Kündigen von Änderungsmitteilungen. Class-type hints erlauben hierbei gleich die Voraussetzung zu definieren, dass der im Funktionskopf übergebene subscriber das subscriber Interface implementiert haben muss. Auch wenn der Name „class-type hint“ etwas anderes suggeriert: Es können nicht nur Klassentypen sondern auch implementierte Interfaces verlangt werden.  Das subscriber Interface wiederum definiert die callback Methode, an die der publisher seine Mitteilungen senden kann. Da hier das Pull-Verfahren Anwendung findet, existiert kein Parameter, der erweiterte Angaben über die am publisher gemachten Änderungen machen könnte.
Das dritte Interface, provideRole, ist vom Prinzip her nicht unbedingt erforderlich für dieses Beispiel, demonstriert aber erneut den Grundgedanken der losen Kopplung zwischen subscriber und publisher: es verhindert, dass der subscriber den Klassentyp des publishers kennen muss. Solange die Bezeichnung und Signatur der zuständigen Methode gleich bleibt, ist der Klassentyp austauschbar.
Als publisher zeigt das Listing 2  mit der Klasse user eine stark vereinfachte Klasse zur Verwaltung eines Users. Diese implementiert die Interfaces publisher und getRole. Mit Hilfe der Methoden user::setRole() und user::getRole() bietet sie lediglich die Möglichkeit, eine Benutzerrolle in Form einer Integer-Zahl zu setzen und auch wieder abzufragen. Alle darüber hinausgehenden Methoden dienen dem Beobachter-Muster.
Listing 3 zeigt die Klasse rights. Sie fungiert als subscriber und implementiert das gleichnamige Interface. Ihre Aufgabe ist die Verknüpfung von Benutzerrollen mit Benutzerrechten. Auch sie bietet nach außen hin neben den Methoden, die dem Beobachter-Muster vorbehalten sind, lediglich die Möglichkeit mit rights::get() eine Auflistung der aktuellen Benutzerrechte abzufragen.
Den Beweis der Funktionalität und Praktikabilität tritt schlussendlich das Listing 4 an. Dort werden Exemplare (Objekte) der Userklasse und Rechteklasse erzeugt. Dabei wird dem Rechteobjekt eine Referenz auf die Userklasse übergeben. Das Rechteobjekt fragt bei dessen Erzeugung im Konstruktor die Benutzerrolle beim per Referenz übergebenen Userobjekt ab und abonniert dessen Änderungsmitteilungen. Das Userobjekt legt daraufhin einen Verweis auf das Rechteobjekt in seiner Abonnentenliste user::subscribers ab.
Nun werden die Rechte der momentanen Benutzerrolle (Rolle 0) beim Rechteobjekt abgefragt (rights::get()) und das zurückgegebene Array zur Kontrolle ausgegeben: Die enthaltenen Benutzerrechte beschränken sich auf Leserechte (read). Anschließend wird dem Userobjekt eine neue Benutzerrolle (Rolle 1) zugewiesen und das Rechteobjekt erneut abgefragt, das zurückgelieferte Array enthält diesmal Lese- und Änderungsrechte (read, change). Ein letztes Mal wird die Benutzerrolle geändert (Rolle 2) und die Benutzerrechte beim Rechteobjekt abgefragt, welches dieses Mal Lese-, Änderungs- und Erstellungsrechte (read, change, create) zurückliefert.
Die Funktionstüchtigkeit des Entwurfs ist damit zweifelsfrei nachgewiesen: Da Rechteobjekt bei einer Anfrage nach den Rechten keine Abfrage an das Benutzerobjekt stellt, aber dennoch alle Rechte der jeweils aktuellen Benutzerrolle zurückliefert, muss das Benutzerobjekt Änderungen der Benutzerrolle zwischenzeitlich dem Rechteobjekt mitgeteilt haben.
Betrachten wir die Abläufe beim Ändern der Benutzerrolle genauer: Nach Aufruf der Methode user::setRole() benachrichtigt das Benutzerobjekt per user::notifySubscribers() alle im Array user::subscribers als Referenz abgelegten Abonnenten und ruft jeweils deren notfiy() Methode auf. So benachrichtigt, fragt das Rechteobjekt die aktuelle Benutzerrolle des Userobjektes ab (rights::loadUserRights()) und speichert die assoziierten Benutzerrechte im Array rights::rights. Eine Abfrage der Benutzerrechte am Benutzerobjekt mit rights::get() liefert dieses Array zurück ohne eine erneute Anfrage an das Benutzerobjekt zu stellen.
Der in den Listings abgedruckte Quellcode ist aus layouttechnischen Gründen gekürzt, aber lauffähig. Die vollständige Fassung findet sich mit ausführlichen phpDoc Kommentaren versehen auf der CD, die diesem Heft beiliegt.

Push or Pull?
Das Beobachter-Entwurfsmuster kann als Push- oder als Pull-Verfahren implementiert werden. Im in diesem Artikel vorgestellten Pull-Verfahren werden die Abonnenten lediglich darüber in Kenntnis gesetzt, dass eine Änderung am Zustand des publishers stattgefunden hat, nicht aber welche Änderung das war. Dies müssen die Abonnenten selbst in Erfahrung bringen. Das Push-Verfahren hingegen schickt zusätzlich Informationen über die gemachten Änderungen an alle Abonnenten, welche die Relevanz der Informationen evaluieren können.
Beide Verfahren haben Ihre Vor- und Nachteile: Zwar muss beim Pull-Verfahren der Abonnent bei jeder Benachrichtigung prüfen, ob die Änderungen am Zustand publishers für ihn relevant sind, doch bleibt dafür die Menge der vom Verteiler gesendeten Daten klein. Beim Push-Verfahren hingegen kann der Abonnent anhand der ihm gelieferten Daten selbst entscheiden, ob eine Aktion notwendig ist und muss nicht erst zusätzliche Anfragen an den publisher stellen, dafür erreichen alle vom publisher gesendeten Daten alle Abonnenten, auch wenn die Daten für einige Abonnenten irrelevant sind. Auch die hierfür benötigte API und Auswertungslogik jedes Abonnenten ist weit komplexer als es beim Pull-Verfahren der Fall ist.

Das Beobachter-Muster in PHP4
Das im Rahmen dieses Artikels vorgestellte Beispiel macht intensiven Gebrauch der neuen PHP5 Sprachkonstrukte. Dennoch ist es ohne größeren Aufwand möglich, den Code nach PHP4 zu portieren. Der Verzicht auf Interfaces, sowie auf die public/private/protected Deklarationen, fordert vom Programmierer allerdings etwas Disziplin beim Einhalten von Objekt-Integritäten um die lose Kopplung von Objekten (und damit deren Austauschbarkeit) nicht zu gefährden. Auch ist bei allen Übergaben von Objekten darauf zu achten, dass PHP4 (anders als PHP5) kein standardmäßiges pass-by-reference macht, sondern Kopien der übergebenen Objekte anlegt. Abhilfe schafft hier die Verwendung des &$objekt Konstrukts oder die des &= Operators für explizite Referenzen.

Bewertung
Das Beobachter-Muster ist in seiner Anwendung nicht an Spezialfälle gebunden und kann überall zum Einsatz kommen, wo Objektabhängigkeiten bestehen. Dies macht es zu einem der bekanntesten und am meisten verwendeten Entwurfsmuster. Eine Transferleistung ist fast nicht nötig, die hier vorgestellte API dürfte nahezu unverändert auf 90% der Fälle, wo ein Pull-Verfahren zur Anwendung kommen soll, zutreffen. Aber auch das Beispiel in ein Push-Verfahren zu ändern geht ohne größeren Anwand.
Eine Besonderheit hat das Beobachter-Muster zu bieten: Im Gegensatz zu den im Verlauf dieser Artikelserie bereits vorgestellten Entwurfsmustern führt dieses Muster nicht zu signifikanten Performanceeinbussen. Das Prinzip vieler anderer Entwurfsmuster ist die Einführung einer Interdirektionsebene (siehe Ausgabe 01/2004, Artikel „Strickwerk“, Box „Flexibilität vs. Performance“). Auf einen solchen Overhead an Codezeilen, die bei jeder Aktion anfallen, kann das Beobachter-Muster verzichten: Alle automatisch und zusätzlich zur Skriptanweisung ausgeführte Befehle müssten bei Nichtanwendung des Musters auch manuell ausgeführt werden (bis auch Abonnieren/Kündigen).
In der Gesamtheit betrachtet dient das Beobachter-Muster vornehmlich der Bequemlichkeit des Programmierers, der sich das Berücksichtigen von Abhängigkeiten sparen kann, sobald er diese einmal per Abonnement definiert hat. Einmal mehr findet sich die Weisheit bestätigt, dass „Programmierer von Natur aus faul sind“. Aber auch eine passende Ausrede steht schon parat: Als Nebeneffekt der Anwendung des Musters wird die Konsistenz der Anwendung sichergestellt. Dies geschieht, da, nachdem eine Abhängigkeit per Abonnement definiert wurde, diese fortan bei keiner Aktion mehr vergessen wird.
Der nächste Teil der Serie behandelt den Dekorierer und stellt damit eine Möglichkeit vor, Objekte dynamisch um Methoden zu erweitern. Mit Hilfe des Dekorierers kann der Funktionsumfang eines Objektes flexibel geändert werden ohne dass Methoden statisch von einer Elternklasse geerbt werden müssten; Ein adäquater Ersatz für die in PHP fehlende Mehrfachvererbung.
 interface publisher {
    public function subscribe(subscriber $subscriber);
    public function unsubscribe(subscriber $subscriber);
}

$user->setRole(2);
print_r($rights->get());