Ein gutes Buch! Ich bereue keineswegs 50€ dafür ausgegeben zu haben. Werde es aber auch nochmal irgendwann auf englisch in die Hände bekommen müssen, wegen des Vokabulars.

Wie der Name schon sagt, handelt es von Entwurfsmustern. Diese Muster beschreiben wie man Objekte in Beziehung setzen kann, Arten von Beziehungen die gut funktionieren. Es hilft bei Problemlösungen und zeigt auf, wie eine Analyse auszusehen hat. Die Beschreibungen laufen über Vor- und Nachteil und detaillierte Beispiele.

Ich bin immer noch sehr dabei diese Art des Programmierens zu lernen, komme einem guten Niveau aber immer näher. Derweil versuche ich noch die Rolle von Prototypen in JavaScript zu verstehen um dann, selbst in JavaScript, Entwurfsmuster anzuwenden.

Vorerst muss ich darauf hinweisen, dass ich kein Profi bin und hier meine subjektive Meinung vertrete. Dies wird also kein Eintrag wie aus dem Lehrbuch, ich versuche nur etwas auf meine Weise klar zu machen.

Einleitung der GoF: Favorisiere Zusammensetzung vor Vererbung (“Favor object composition over class inheritance”)

Vererbung sollte für jeden, der schon mal ein paar Klassen geschrieben hat, klar sein; Stichwort dazu ist (in PHP) “extends”. Zusammensetzung ist schon ein wenig schwieriger. Ich bin mir nicht mal sicher, ob das auch wirklich die perfekte Übersetzung für Composition ist. Die wichtigste Rolle spielt hier der Dekorierer.

Hier nun ein bischen PHP-Code, hoffentlich schon selbsterklärend:

interface Etwas
{
    public function tuWas();
}
class EtwasImplementation implements Etwas
{
    public function tuWas()
    {
        return 'Etwas tut was.';
    }
}
class AnderesEtwas implements Etwas
{
    public function tuWas()
    {
        return 'Dieses Etwas tut was Anderes, evtl. Ähnliches auf andere Weise.';
    }
}
class EtwasDekorierer implements Etwas
{
    protected $_Etwas;
    public function __construct(Etwas $Etwas)
    {
        $this->_Etwas = $Etwas;
    }
    public function tuWas()
    {
        return $this->_Etwas->tuWas().' Und der Dekorierer verarbeitet das noch weiter, kann jedes Etwas erweitern.';
    }
}

Wie man sieht ist der EtwasDekorierer selbst ein Etwas, kann auch jeder Zeit die Stelle eines Etwas einnehmen, wie als würde er davon abstammen (Vererbung). Der klare Vorteil gegenüber der Vererbung ist nun, dass der EtwasDekorierer sowohl die EtwasImplementation als auch AnderesEtwas erweitern kann. Das, was erweitert wird, wird dadurch austauschbar. Mehrere Dekorierer lassen sich übrigens hervorragend verschachteln.

Hier noch ein kleines, etwas konkreteres Beispiel:

class Logger # soll Methodenaufrufe des dekorierten Objekts loggen.
{
    protected $_Object;
    public function __construct($Object) #ggf prüfen ob es ein Objekt eines bestimmten Typs ist (per Typehint)
    {
        $this->_Object = $Object;
    }
    public function __call($method, $args);
    {
         printf('Methode %s eines Objekts der Klasse %s wurde aufgerufen \n', $method, get_class($this->_Object));
         # Hier kann man natürlich je nach Bedarf etwas Anderes einbauen... (e.g. In Datei schreiben etc.etc..)
         return call_user_func_array(array($this->_Object, $method), $args);
    }
}

Der Nachteil am Dekorierer ist, dass man alles delegieren, also weiterleiten, muss. Besonders wenn der Dekorierer nur einen Teil der Methoden verändern soll ist das nervig alle Methoden an das dekorierte Objekt weiterzuleiten. PHP5s __call() kann da praktisch sein, obwohl dann zu überdenken ist, ob der Dekorierer nicht unnötig ist, gerade in PHP, wo OOP weniger performant ist.

Insgesamt wird mit dem Dekorierer eine weniger feste Bindung zwischen den Objekten gelegt, dadurch wird das Design flexibler.

Wenn Programmieren abstrakt ist, dann sind es Entwurfsmuster erst recht. Die Beschreibungen der Muster sind gar so abstrakt, dass man umbedingt Beispiele für die Anwendung braucht.

Auch wenn man sie leicht übersieht, stehen bereits im PHP Handbuch zwei Entwurfsmuster. Singleton und Fabrik. Ich möchte auf Singleton eingehen, hole aber noch etwas weiter aus.

Ich habe mich, als ich OOP anfing, gewundert wofür die public, protected und private Deklarationen sind und denn Sinn einfach nicht verstanden. In PHP dienen sie größtenteils gar nicht dem Programmierer selbst, sondern anderen Programmierern, die am selben Projekt schreiben. Sie schließen einfach die falsche Verwendung aus und kapseln Funktionen und Eigenschaften durch die Zugriffkontrolle. Für die Codefunktionalität sind sie somit unwichtig. Man könnte auch einfach alles public deklarieren, wenn man es trotzdem richtig verwendet (PHP4 ist noch alles public).

Singleton geht auf diesem Weg weiter, er erlaubt nur eine Instanz eines bestimmten Objektes, auf welche gleichzeitig global zugegriffen werden kann.

Das benötigt man zum Beispiel bei der Datenbank, die meist nur eine einzige Verbindung umfasst.

http://docs.php.net/manual/de/language.oop5.patterns.php

Es gibt aber noch viele andere komplexere Entwurfsmuster. Ich werde demnächst nochmal das neue Schema für mein Projekt erklären.

Entwurfsmuster zählen definitiv zur Professionellen Programmierung, das Niveau ist deutlich anders, als das simple Programmieren von einfachen Websites.