Zur Verdeutlichung sind jetzt auch zwei andere Klassen ins Spiel gekommen Client A und B. Diese verwenden die Registry schreibend und lesend, sodass wir die Verwendung der Registry besser nachvollziehen können. Die Registry besteht neben dem Singleton im Prinzip nur aus Verwaltungsmethoden für das Speichern, Löschen, und Zurückgeben von Daten.

Begeben wir uns nun zunächst an die Definition des Interfaces und die Implementation der Registry, bevor wir die Clients auf unsere Daten los lassen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

interface Registry
{
	public static function getInstance ();
	public function register ( $key , $value );
	public function unregister ( $key );
	public function get ( $key );
}
 
class DataLayer implements Registry
{
	protected static $Instance = NULL;
	protected $Registry = array();
 
	protected function __construct ()
	{
 
	}
 
	protected function __clone ()
	{
 
	}
 
	public static function getInstance()
	{
		if ( self::$Instance === NULL )
		{
			self::$Instance = new self;
		}
 
		return self::$Instance;
	}
 
	public function register ( $key , $value )
	{
		$this->Registry [ $key ] = $value;
	}
 
	public function unregister ( $key )
	{
		unset ( $this->Registry [ $key ] );
	}
 
	public function get ( $key )
	{
		return $this->Registry [ $key ];
	}
}

Konstruktor und clone sind wieder zu Gunsten von Singleton deaktiviert bzw. protected deklariert. Die Methoden sollten selbsterklärend sein (wie schon so oft vorher ). Jetzt müssen wir noch die Clients implementieren. Diese sind ganz rudimentär, aber erfüllen in diesem Fall den Demozweck:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

class Client_A
{
	public function setData ( $Data )
	{
		DataLayer::getInstance()->register ( 'testdata' , $Data );
	}
}
 
class Client_B
{
	protected function getData ( )
	{
		return DataLayer::getInstance()->get ( 'testdata' );
	}
 
	public function printData()
	{
		var_dump($this->getData());
	}
}

Wie wir sehen wird Client_A Daten in die Registry speichern und Client_B diese wieder auslesen und direkt darstellen. Nun müssen wir nur noch ein Testscript schreiben. In diesem werden $Logic und $Display direkt hintereinander instanziiert, das ist in der Regel nicht so .

1
2
3
4
5
6
7
8
9
10
11

$Logic = new Client_A;
$Logic->setData
(
	array
	(
		'foo' => 1,
		'bar' => 2
	)
);
$Display = new Client_B;
$Display->printData();

Wenn wir dieses Script nun ausführen, sehen wir anhand des Outputs, dass alles korrekt funktioniert:

Array
(
[foo] => 1
[bar] => 2
)

Nun haben wir gesehen wie wir Klassen mit Informationen versorgen können, ohne dass sie einander kennen müssen. Die Datenschicht kann, aufgrund fix definierter Schnittstellen beliebig ausgetauscht werden, solange die neue Schicht die selben Schnittstellen implementiert.

Bei Fragen wie gehabt, einfach einen Kommentar hinterlassen (oder auch wenn’s gut war oder geholfen hat?) .

Um die Commands noch ein wenig an einander anzugleichen könnten wir auch zunächst eine Abstract definieren, anstatt eines Interfaces, und so direkt Methoden (Implementationen nicht Schnittstellen!!) weitervererben, die in allen Commands gleich sein soll. In unserem Fall begnügen wir uns mit den Interfaces.

Widmen wir uns zunächst der Implementation der beiden Interfaces für den Invoker und das Command:

1
2
3
4
5
6
7
8
9
10
11

interface Invoker
{
	public function add ( Command $Action );
	public function remove ( Command $Action );
	public function run();
}
 
interface Command
{
	public function execute();
}

Die Definition der Schnittstellen ist immer wichtig. Denn nur so können wir sicherstellen, dass Klassen, die in dieser Struktur laufen sollen, später auch wirklich hinein passen.
Wie wir sehen bekommt der Invoker zwei Verwaltungsfunktionen (um Commands hinzuzufügen und zu entfernen) und zusätzlich noch eine Methode um alle Commands auszuführen. Das Command bekommt in unserem Fall nur eine execute-Methode. Intern kann natürlich ein Kommando viele Methoden haben, die für die Ausführung nötig sind, jedoch ist für die Struktur nur wichtig, dass die entsprechenden Command Methoden auf jeden Fall implementiert sind.

In unserem Fall müssen wir noch 3 Klassen implementieren:

- den Invoker (Batch)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

class Batch implements Invoker
{
	protected $Commands = array();
 
	public function add ( Command $Command )
	{
		$this->Commands[] = $Command;
	}
 
	public function remove ( Command $Command )
	{
		$this->Commands = array_diff($this->Commands, array($Command));
	}
 
	public function run()
	{
		echo "Verarbeitung der Anweisungen gestartet ...<br />";
		echo "============================================<br />";
		foreach ( $this->Commands as $Command )
		{
			$Command->execute();
		}
		echo "============================================<br />";
		echo "Verarbeitung der Anweisungen beendet ...<br />";
	}
}

- ein Command (Install)

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class Install implements Command
{
	protected $name = NULL;
 
	public function __construct ( $name )
	{
		$this->name = $name;
	}
 
	public function execute()
	{
		echo "+" . $this->name . ' wurde installiert<br />';	
	}
}

- ein Command (Uninstall)

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class UnInstall implements Command
{
	protected $name = NULL;
 
	public function __construct ( $name )
	{
		$this->name = $name;
	}
 
	public function execute()
	{
		echo "-" . $this->name . ' wurde deinstalliert<br />';	
	}
}

Ich denke die Methoden sollten selbsterklärend sein. Der Einfachheit halber geben diese Kommandos nur aus was sie tun. Beim Instanziieren geben wir ihnen einen Namen mit wie z.B. Db-Treiber. Die wirkliche Funktionalität kann ja bei Bedarf hinzugefügt werden. Mir geht es hier nur um die Verdeutlichung des Musters.

Nun schreiben wir uns noch ein kleines Testscript:

1
2
3
4
5

$Batch = new Batch;
$Batch->add ( new Uninstall ( 'Pear::DB' ) );
$Batch->add ( new Install ( 'Pear::MDB2' ) );
$Batch->add ( new Install ( 'Pear::XmlTree' ) );
$Batch->run();

Hier instaniziieren wir unser Batch-Objekt und übergeben über die add-Methode drei Commands, die dann in die Queue eingereiht werden und dann in dieser Reihenfolge ausgeführt werden.
Wenn wir dieses Script nun laufen lassen, können an der Ausgabe erkennen, dass unsere Batch-Routine erfolgreich durchgelaufen ist:

Verarbeitung der Anweisungen gestartet …
============================================
-Pear::DB wurde deinstalliert
+Pear::MDB2 wurde installiert
+Pear::XmlTree wurde installiert
============================================
Verarbeitung der Anweisungen beendet …

Wie wir nun gesehen haben kann man mit diesem Muster leicht beliebige Befehle kombinieren. Möchte man allerdings, dass die Befehle geschachtelt werden können, also einen Baum darstellen sollen, können wir dazu noch zusätzlich das Composite Pattern einsetzen. Dies wird evtl. nächste Woche in einem gesonderten Eintrag erläutert. Wie man die beiden dann kombiniert ist dann sicherlich aus beiden Einträgen herzuleiten .

Bei Fragen, Anregungen etc. einfach einen Kommentar hinterlassen .

Wir definieren zunächst ein Interface, welches die Schnittstelle getInstance definiert. Diese gibt dann die aktuelle Instanz zurück. Anders als bei der “normalen” Implementation von Klassen ist der Konstruktor protected, kann also nicht von außen aufgerufen werden, das heißt, dass die Klasse nicht mit dem new-Operator instanziiert werden kann. Zusätzlich muss die Methode __clone noch protected deklariert werden, damit man durch den Einsatz des clone-Operators keine neuen Instanzen erzeugen kann.

Die Implementation der Klassse sieht so aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

interface Singleton
{
	public static function getInstance ();
}
 
class DbWrapper implements Singleton
{
	protected static $Instance = NULL;
 
	protected function __construct()
	{
 
	}
 
	protected function __clone()
	{
 
	}
 
	public static function getInstance()
	{
		if ( self::$Instance === NULL )
		{
			self::$Instance = new self;
		}
 
		return self::$Instance;
	}
}

Wie wir sehen prüft die Methode getInstance beim Aufruf, ob bereits eine Instanz der Klasse in der statischen Klassenvariable $Instance vorhanden ist und legt sie bei Bedarf vor dem zurückgeben an.
Nun wollen wir schauen, ob unser Vorhaben erfolgreich war und rufen folgendes Testscript auf:

1
2
3
4
5
6
7
8
9
10
11

$SingleWrapperA = DbWrapper::getInstance();
$SingleWrapperB = DbWrapper::getInstance();
 
if( $SingleWrapperA == $SingleWrapperB )
{
	echo 'Wrapper A und Wrapper B sind gleich<br />';
}
else
{
	echo 'Wrapper A und Wrapper B sind NICHT gleich<br />';
}

Die Ausgabe im Browser zeigt uns, dass wir alles richtig gemacht haben und das Anlegen von mehreren Instanzen nicht mehr möglich ist:

Wrapper A und Wrapper B sind gleich

Jetzt könnte es aber nötig sein verschiedene Datenbanktypen zu verwenden und hier jedoch auch nur jeweils eine Instanz zu haben. Schauen wir uns die Veränderung im UML an:

Wie wir sehen übernimmt getInstance nun einen Namen und speichert die Instanz nicht mehr in einer reinen Variable ab, sondern in einem Array, welches die jeweilige Instanz über den Namen zuordnet (alles sehr rudimentär ).

Die Implementation dafür sähe folgendermaßen aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

interface SingletonMulti
{
	public static function getInstance ( $name );
}
 
class
	DbWrapperMulti
implements
	SingletonMulti
{
	protected static $Instance = array();
	protected $name;
 
	protected function __construct()
	{
 
	}
 
	protected function __clone()
	{
 
	}
 
	public static function getInstance( $name )
	{
		if ( !self::$Instance [ $name ] )
		{
			self::$Instance [ $name ] = new self;
			self::$Instance [ $name ]->setName ( $name );
		}
 
		return self::$Instance [ $name ];
	}
 
	public function setName ( $name )
	{
		$this->name = $name;
	}
}

Wir speichern also die entsprechenden Instanzen in einem Array und weisen ihnen darüber hinaus einen Namen zu (ohne diesen wären die Instanzen aller Typen gleich, da es sich um leere Instanzen handeln würde).
Folgendes Script verwenden wir nun, um unsere Klasse zu testen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

$SingleWrapperMySql_A = DbWrapperMulti::getInstance( 'mysql' );
$SingleWrapperMySql_B = DbWrapperMulti::getInstance( 'mysql' );
 
$SingleWrapperPgSql_A = DbWrapperMulti::getInstance( 'pgsql' );
$SingleWrapperPgSql_B = DbWrapperMulti::getInstance( 'pgsql' );
 
if( $SingleWrapperMySql_A == $SingleWrapperMySql_B )
{
	echo 'MySql A und MySql B sind gleich<br />';
}
else
{
	echo 'MySql A und MySql B sind NICHT gleich<br />';
}
 
if( $SingleWrapperPgSql_A == $SingleWrapperPgSql_A )
{
	echo 'PgSql A und PgSql B sind gleich<br />';
}
else
{
	echo 'PgSql A und PgSql B sind NICHT gleich<br />';
}
 
if( $SingleWrapperPgSql_A == $SingleWrapperMySql_A )
{
	echo 'PgSql und MySql sind gleich<br />';
}
else
{
	echo 'PgSql und MySql sind NICHT gleich<br />';
}

Die Ausgabe im Browser zeigt uns, dass die beiden MySql und PgSql Wrapper jeweils gleich sind, jedoch der MySql und der PgSql Wrapper unterschiedlich sind.

MySql A und MySql B sind gleich
PgSql A und PgSql B sind gleich
PgSql und MySql sind NICHT gleich

Somit haben wir unser Ziel erreicht mehrere Typen des Wrappers jeweils einmal zu instanziieren.

Unser Object “Statistics” enthält als 1-n “Objekte” von Typ “Average” und “Sum”. Diese werden zu Beginn registriert und werden ab sofort bei jeder Änderung der Daten in “Statistics” benachrichtigt. Wir können noch beliebig viele andere Observer-Klassen implementieren, z.B. zum Ausgeben von Diagrammen etc. Dies erfordert nur eine zusätzliche Implementation des Observers.

Legen wir zunächst die Interfaces für unsere Klassen an. Damit stellen wir sicher, dass wir die benötigten Schnittstellen bereitstellen, damit das Muster korrekt arbeiten kann:

1
2
3
4
5
6
7
8
9
10
11
12

interface Subject
{
	public function attach (Observer $Observer);
	public function detatch (Observer $Observer);
	public function notify();
}
 
interface Observer
{
	public function update (Subject $Subject);
	public function printResult ();
}

Gehen wir kurz die Methoden einzeln durch:

Subject::attach
… bietet die Möglichkeit Observer für die Datenquelle zu registrieren.

Subject::detach
… bietet die Möglichkeit Observer von der Datenquelle zu entfernen.

Subject::notify
… benachrichtigt die registrierten Observer über Änderungen auf der Datenquelle.

Observer::update
… aktualisiert die Daten des Observers bei jedem Update über die Datenquelle

Observer::printResult
… gehört nicht zur Originalimplementation des Observerpatterns, hier führen wir sie trotzdem auf, da wir von jedem Observer erwarten, dass er seine Ergebnisse ausgeben kann.

Schauen wir uns nun die Implementation des Subjects an. Die Methoden sollten eigentlich für sich sprechen. Die Methode setData() wird verwendet, um Daten des Subjects zu ändern. Im Konstruktor wird der initale Datenbestand übergeben. Dieser wird beim Registrieren eines jeden Observers auf dem Subject an den Observer übergeben:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

class Statistics implements Subject
{
	protected $Data = array();
	protected $Observers = array();
 
	public function __construct ( $Data )
	{
		$this->setData( (array)$Data );
	}
 
	public function attach (Observer $Observer)
	{
		$Observer->update ( $this );
		$this->Observers[] = $Observer;
	}
 
	public function detatch (Observer $Observer)
	{
		$this->Observers = array_diff($this->Observers, array($Observer));
	}
 
	public function notify()
	{
		foreach($this->Observers as $Observer)
		{
			$Observer->update ( $this );
		}
	}
 
	public function setData ( $Data )
	{
		$this->Data = (array)$Data;
		$this->notify();
	}
 
	public function getData()
	{
		return $this->Data;
	}
}

Nachdem wir nun das Subject implementiert haben, müssen wir die jeweiligen Darstellungsformen implementieren. Die update-Methode ist, wie gesagt, dazu bestimmt die Daten des Subjects aufzunehmen und aufzubereiten. Ich denke der Rest muss nicht weiter kommentiert werden

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

class Sum implements Observer
{
	protected $Data = array();
 
	public function update(Subject $Statistics)
	{
		$this->Data = $Statistics->getData();	
	}
 
	public function printResult()
	{
		echo __CLASS__ . ": " . sprintf( "%01.2f" , array_sum ($this->Data) ) . "<br />";
	}
}
 
class Average implements Observer
{
	protected $Data = array();
 
	public function update(Subject $Statistics)
	{
		$this->Data = $Statistics->getData();
	}
 
	public function printResult()
	{
		echo __CLASS__ . ": " . sprintf( "%01.2f" , (array_sum ($this->Data) / count($this->Data) ) ) . "<br />";
	}
}

Nachdem wir auch dies erledigt haben, bauen wir ein kleines Testscript, welches die Funktionalitäten testet. Wir übergeben zunächst ein Array mit Daten an das Subject, registrieren zwei Observer und lassen die Daten ausgeben. Anschließend ändern wir die Daten auf dem Subject und lassen die Daten der Observer erneut ausgeben:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

$Data = array
(
	123.4,
	982.2,
	329,1
);
 
$Data2 = array
(
	$Data[1],
	$Data[2]
);
 
$StatisticData = new Statistics ( $Data );
$SumPager = new Sum();
$AveragePager = new Average();
$StatisticData->attach ( $SumPager );
$StatisticData->attach ( $AveragePager );
$SumPager->printResult();
$AveragePager->printResult();
echo "---------Nach Datenaenderung---------<br />";
$StatisticData->setData ( $Data2 );
$SumPager->printResult();
$AveragePager->printResult();

Folgende Ausgabe wird nun im Browser erzeugt, wie wir sehen, hat alles gut funktioniert und die Daten sind erfolgreich geändert worden:

Sum: 1435.60
Average: 358.90
———Nach Datenaenderung———
Sum: 1311.20
Average: 655.60

Dies war also ein kleiner Chrashkurs für das Observer-Pattern in PHP 5. Bei Fragen, Anregungen etc. einfach einen Kommentar hinterlassen .