Nachdem ich mich jetzt während des Sommers mit Objektorientierung, Softwarearchitektur und Entwurfsmustern beschäftigt hatte, suchte ich auch in JavaScript nach Mustern und Best Practice, und  nun möchte ich diese Erfahrungen auf meinem Blog teilen.

Vorab sollte erwähnt werden, dass JavaScript in mehreren Aspekten eine besondere Sprache ist. Es wird nicht umsonst geschmäht aufgrund unerklärlichen Verhaltens. Man sehe sich nur mal wtfjs an! Dennoch ist JavaScript auch sehr mächtig als objektorientierte Sprache. Closures und Prototypen sind recht unbekannt in der sehr von Java geprägten objektorientierten Welt. Die Umgewöhnung kann schwer fallen, auch ich hatte da meine Probleme. Zum Glück gibt es zum Beispiel Videos von Douglas Crockford auf YUI Theater, die einem helfen einen Einstieg zu finden.

Ich möchte nun hier zwei Funktionen vorstellen, die es auch in die neue ECMAScript Spezifikation geschafft haben: Function.prototype.bind und Object.create. Beide lassen sich mit einigen Tricks auch auf dem momentan verbreiteten JavaScript verwenden, bei Frameworks gehören sie zum Grundrepertoire.

Viel kann ich noch nicht zu prototypenbasierter Programmierung sagen, da ich selbst noch nicht ganz auf den Trichter gekommen bin, trotzdem habe ich schon Anwendungen gefunden und ziehe Nutzen in meinem sonst noch recht klassenbasierten Stil.

Object.create

if (typeof Object.create !== 'function') {
    Object.create = function (o) {
        function F() {}
        F.prototype = o;
        return new F();
    };
}

Diese schöne Funktion erzeugt ein Objekt auf Basis eines anderen Objekts, welches zum Prototypen wird. Vorsichtig muss man sein, wenn man lokale/private Variablen im Prototypen verwendet, da sich die beiden Objekte diese teilen. Der Prototyp sollte also ein neues Objekt sein, dass sonst nicht genutzt wird, oder die vermeintlichen Methoden müssen neu initialisiert werden, wie ich es in vorigem Blogeintrag mit dem aufrufen eines Konstruktors mache.

Ich möchte das Beispiel auch nochmal aufgreifen, wobei ich mittlerweile nochmal refaktorisiert habe.

Resource.prototype.create = function(newAmount) {
    var newResource = Object.create(this);
    Resource.call(newResource, newAmount, this.getType());
    return newResource;
};

Mit dieser Methode ist es möglich Objekte der selben Resource anhand einer vorliegenden zu erstellen. Theoretisch könnte ich diese Methode auch clone() nennen, da ich aber gleichzeitig das neue Objekt initialisiere, behalte ich den namen der Basisfunktion – create(). clone() lässt sich damit aber recht leicht verwirklichen, man muss nur die Eigenschaften vom alten Objekt übergeben.

Resource.prototype.clone = function() {
    return this.create(this.getAmount());
}

Schön, jetzt habe ich ein paar tolle neue Möglichkeiten Objekte zu erzeugen, was soll das nun?
Unter den Entwurfsmustern gibt es eine Untermenge: Creational Patterns, Muster zur Konstruktion. Einige Muster, die sich mit verschiedenen Möglichkeiten der Konstruktion von Objekten beschäftigen. Alle vermeiden die Konstruktion mittels “new <Klassenname>”, weil dies (unter anderem) zu statisch ist.
Wenn ich ein Objekt mit einer create() Methode übergebe, dann übergebe ich gleichzeitig die Möglichkeit ein neues Objekt des selben Typs zu erstellen, ohne mich explizit an den Typ zu binden. Die Konstruktion ist dynamisch. Aus diesem Grund kann ich auch leicht Vererbung anwenden ohne danach meinen ganzen Code nach “new <Elternklassenname>” durchsuchen zu müssen.

Function.prototype.bind

if (typeof Function.prototype.bind !== "function") {
    Function.prototype.bind = function(context) {
        if (arguments.length < 2 && typeof arguments[0] === "undefined") {
            return this;
        }
        var method = this, args = Array.prototype.slice.call(arguments, 1);
        return function() {
            var a = merge(args, arguments);
            return method.apply(context, a);
        };
    };
}

Den Code dieser Funktion habe ich mir aus dem Prototype Framework geholt und von Abhängigkeiten befreit. Jede Funktion und insbesondere Methode ist ab jetzt mit der Funktionalität ausgerüstet, unabhängig von ihrem Objekt gemacht zu werden.
Schonmal das probiert?

var func = someObject.someMethod;
func();

Das geht schwer in die Hose wenn someMethod “this” verwendet, “this” is dann nämlich “window” – eine der Freuden an JavaScript.
Stattdessen verwendet man besser:

var func = someObject.someMethod.bind();

Theoretisch kann man auch bereits Parameter mitgeben.
Diese Funktion findet häufig Verwendung, wenn man bei AJAX oder Effekten Callbacks übergibt und spart jedes Mal manuelles Umwickeln mit einer anonymen Funktion.

Die Tiefe von Patterns habe ich mit diesem Artikel wohl nicht erreicht, aber ich hoffe er ist trotzdem einigen Leuten hilfreich. Die vorgestellten Funktionen würde man wohl als Sugar (“Zucker”) bezeichnen.

Gleichzeitig handelt es sich um das Muster Wertobjekt (ValueObject), welches unveränderlich ist.

Vorweg muss noch gesagt werden, dass alle Attribute als Konvention protected gelten, public wird nicht benötigt und private lässt sich über Closures realisieren. Einfache Attribute tragen zudem den Anfangsbuchstaben ihres Typs (z.B. s für String).

Objekte der Klasse stellen eine Menge eines Rohstoffs dar.

/**
 * Represents an amount of a resource
 * @param {number} amount
 * @param {string} type
 */
function Resource(amount, type) {
    var nAmount = amount;
    var sType = type;

    if (amount < 0) {
        throw new IllegalArgumentException("amount has to be positive");
    }

    /**
     * @method Resource
     * @return {number} amount of the resource
     */
    this.getAmount = function() {
        return nAmount;
    };

    /**
     * @method Resource
     * @return {string} resource type
     */
    this.getType = function() {
        return sType;
    };
}

/**
 * Addition of two resources produces a new resource with the sum amount
 * the new object uses the old one as prototype
 * @param {Resource} resource
 * @return {Resource} new Resource object
 */
Resource.prototype.plus = function(resource) {
    if (!(resource instanceof Resource && this.getType() == resource.getType())) {
        throw new IllegalArgumentException("resources don't match.");
    }
    var newRes = Object.create(this); // create a new object based on the current one
    // execute the Resource constructor on it
    Resource.call(newRes, this.getAmount() + resource.getAmount(), this.getType());
    return newRes;
};

/**
 * Subtraction of two resources produces a new resource with a smaller amount
 * @param {Resource} resource
 * @return {Resource} new Resource object
 */
Resource.prototype.minus = function(resource) {
    if (!(resource instanceof Resource && this.getType() == resource.getType())) {
        throw new IllegalArgumentException("resources don't match.");
    }
    if (this.getAmount() < resource.getAmount()) {
        throw new IllegalArgumentException("can't substract a higher amount");
    }
    var newRes = Object.create(this);
    Resource.call(newRes, this.getAmount() - resource.getAmount(), this.getType());
    return newRes;
};

Interessant ist vor allem die Stelle, an der dynamisch neue Objekte der selben Klasse zurückgegeben werden (plus() und minus()), ich möchte Resource noch erweitern können und evtl. für die verschiedenen Rohstoffsorten eigene Klassen ableiten, daher sollten diese Methoden dann nicht nach einer mathematischen Operation auf die Klasse Resource zurückschrumpfen. In PHP kann man “new” einfach einen String übergeben, in Java muss man einen Umweg über eine Factory oder Reflection machen.

In JavaScript bietet es sich an, das momentane Objekt als Prototyp für das neue zu verwenden und dieses durch den Resource Konstruktor zu initialisieren.

Ich weiß noch nicht, ob mir dieses Pattern noch öfter begegnen wird, aber vor allem bei Wertobjekten (ValueObject), die mit Vererbung erweiterbar bleiben sollen ist dies praktisch. Allgemein wenn man ein neues Objekt des selben Typs wie das momentane zurückgeben möchte.

Jetzt kann ich eine Kindklasse ResourceContainer schreiben, die noch Funktionalität für Gewicht und Volumen des Rohstoffs bereitstellt (z.B zum Beladen von Schiffen):

/**
 * stores resources, adds weight and volume to a resource object
 * @inherits Resource
 * @param {Object} amount
 * @param {Object} type
 */
function ResourceContainer(amount, type) {
    Resource.call(this, amount, type); // inherit priviledged Resource methods
}
ResourceContainer.prototype = Object.create(Resource.prototype); // inherit nonpriviledged Resource methods

Resource.DESITY.metal = 7.85;
Resource.WEIGHT.metal = 1000;

/**
 * @return {number} weight of the resoure amount
 */
ResourceContainer.prototype.getWeight = function() {
    return this.getAmount() * Resource.WEIGHT[this.getType()];
};

/**
 * @return {number} volume of the resource amount
 */
ResourceContainer.prototype.getVolume = function() {
    return this.getAmount() * Resource.DENSITY[this.getType()];
};

Ich beginne langsam die Prototypennatur von JavaScript zu verwenden, bin aber immer noch sehr von Klassen von PHP und Java geprägt.

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.

Leider muss ich zugeben, dass ich in den letzten Wochen nicht wirklich vorwärts gekommen war. Fehlende Motviation und Wissen waren wohl die Gründe. Momentan begreife ich die Objekt-Orientierung in JavaScript, die doch relativ schwierig zu entdecken ist, zumindest war sie das für mich. Wohl einfach aufgrund der größtenteils funktionalen Verwendung von JS. JS OOP programmiert sich zudem ganz anders wie PHP OOP, weil JavaScript vorallem auf Prototypen setzt.

Bei einer Website können mittlerweile client- und serverseitig Skripte aufgerufen werden, der Trend tendiert zur Zeit vor allem zur Clientseite, wobei es immer noch der Server ist, der die wirkliche Validation übernehmen muss. Der Client bleibt manipulierbar und somit unsicher. Auch ich habe mich dem Trend angeschlossen. Dabei setze ich vor allem auf OOP in JS und verlagere so viel wie möglich in den Browser. So wird die Seite bei mir von JavaScript generiert und läd nicht neu. Alles läuft über XHR (XMLHttpRequests – AJAX) und JavaScript. JS bestimmt wie die Seite aussieht, der Server gibt nur noch den Rahmen vor, erlaubt bestimmte Dinge (Zugriffe auf Daten), die Aufbereitung übernimmt der Browser.

Im MVC Modell gesehen verwaltet JavaScript hier die Views und bekommt dafür auch Models zur Verfügung gestellt, wenn auch eingeschränkter als auf PHP-Seite. Die Models stehen trotzdem in einer gewissen Verbindung, auch wenn diese nicht stetig ist, weil ich nicht andauernd unnötige Requests abschicken will, das würde nur zu einer Serverüberlastung führen. Gleichzeitig erzeugt dies einen sehr praktischen clientseitigen Cache, den ich vielleicht von Google Gears unterstützen werde.

Momentan schreibe ich an der Verbindung zwischen Client und Server, die möglichst abstrahiert werden soll (zusammengefasst und einfach verfügbar gemacht) – auch für weitere Entwicklungen.

Für zukünftige Entwickler wird somit auf jeden Fall PHP sowie JS Erfahrung vorrausgesetzt werden. Das schöne an einem Framework ist allerdings, dass man es nicht verstehen muss um es zu benutzen, wenn es gut geschrieben ist und auf kritische Stellen hingewiesen wird. Dafür gibt es zum Glück dann eine Community und Tutorials, die geschrieben werden [uA von mir]. Daher keine Angst, wenn das jetzt alles wie spanisch klang, es wird viele Erklärungen geben.

Ich freue mich schon auf das Verbesserungspotential, das eine Community bietet, wenn man als OpenSource veröffentlicht. Diese Idee treibt mich auch weiterhin an, ich habe aber noch einige schwierige Dinge zu schreiben bevor ich mich überhaupt endlich dem Spielinhalt widmen kann, denn zur Zeit schreibe ich immer noch am Grundgerüst des Spiels, das möglichst variabel und erweiterbar sein soll.

Nun verwende ich zu großen Anteilen die zwei verbreitetsten Websprachen, die beide von vielen Leuten verachtet werden, weil sie vor allem von Amateuren verwendet werden.

Besonders JavaScript scheint eine interessante Vorgeschichte zu haben. Vor einigen Monaten, als ich anfing JS zu lernen, kam ich auf D. Crockford und habe mir seine Videovorträge angesehn. Ich habe JS somit direkt OOP gelernt, wie es sich eigentlich gehört. JS ist sehr objekt-orientiert, Crockford nennt sie “ausdrucksstark”. Die genau Übersetzung ist mir unklar, ist aber auch egal, denke ich.

Ich kann diesen Artikel nur empfehlen, notfalls auch übersetzt, für diejenigen die weniger gut Englisch können. Um Englisch kommt man aber beim Programmieren kaum herum und Crockford schreibt und redet eigentlich ein sehr gut verständliches und deutliches Englisch. Auch seine Videos kann ich nur weiterempfehlen, es lohnt sich!

Ich entwerfe also ein kleines Grundgerüst in JavaScript, das mit dem serverseitigen Teil, den ich in PHP geschrieben habe, zusammenarbeitet. Dabei ist vor allem der ganze AJAX-Kram sehr nervig. Da alles asyncron ist, muss man ständig mit Callbacks arbeiten (Man übergibt die Funktion, die ausgeführt wird, sobald der Request abgeschlossen ist und die Daten zur Verfügung stehen), was ständig zu Verschachtelungen führt, die ich eigentlich umgehen möchte.

Derweil feiere ich mein Abi und mache ein wenig Urlaub mit Freunden. Ich werde also nicht permanent hieran arbeiten, aber hoffentlich dennoch vorwärts kommen.

Beispiel: JavaScript Templateparser

Ich stehe immer noch zu OOP und auch JavaScript untersützt OOP hochgradig, allerdings in einer für PHPler ungewohnten Form: mit Prototypes, ohne Klassen. Überhaupt ist in JavaScript alles ein Objekt oder – noch besser – eine Funktion! Ich habe hier keine Zeit eine JavaScript Einführung zu geben, ich bitte daher um selbständige Fortbildung um diesen Artikel verstehen zu können.

AJAX Requests sind asynchron, laufen also immer mit Callbacks. Ich verwende jQuery als JS-Framework.

$.get(url, function(data) {
    // callback code
});

Wenn ich nun mehrere Requests brauche, weil ich – im Falle des Templateparsers – Template, Sprache und Daten brauche, dann gibt das eine häßliche Verschachtelung:

$.get(tplurl, function(tpl) { // hole Template
    $.get(lngurl, function(lng) { // hole Sprache
        $.get(url, function(data) { // hole Daten
            $.bindTo(tpl, data, lng, '#content'); // parse das Template mit den Daten und der Sprache nach #content
        });
    });
});

Und das ist noch vereinfacht… Dabei hätte ich viel lieber, wobei die Templates und die Sprache gecacht werden sollen:

$.get(url, function(data) {
    $tpl(tplID).bindTo(data, lngID, '#content');
});

Nun.. wie bekommen wir das Callback weg?

Analyse des Problems:

Wir wollen anstatt eines Callbacks eine Verkettung per Punktschreibweise (Objektmethodenaufrufe), das bedeutet die Befehle die auf das Templateobjekt ausgeführt werden, werden höchstwahrscheinlich AJAX Requests beinhalten, auch wenn der Cache verwendet werden kann, müssen wir innerhalb mit Callbacks arbeiten, aber wir können sie nach außen hin verstecken, solange dem Coder gewahr ist, dass der bindTo-Aufruf auch asynchron ist. Für den Fall, dass man doch weiter abhängigen Code hat, führt kein Weg an weiteren Callbacks vorbei.

$tpl(tplID, callback).bindTo(data, params{lang,callback…})

Trotzdem wird das Aussehen komprimiert und etwas lese- und schreibfreundlicher.

Nun, wie ist das im Inneren gelöst?

Wir definieren zuerst eine Funktion get() (private), die das Template auftreibt, sei es aus dem Cache oder per Request. In beiden Fällen führt sie (oder der zugehörige Request) das interne Callback aus, sofern es gesetzt ist.

Das Objekt besitzt nun die public Methode bindTo, welche zuerst das interne Callback definiert (mit dem echten internen bindTo Code) und dann get() aufruft. Dazu kommen noch die beiden äußeren Callbacks von $tpl und bindTo, die wie das interne Callback am Ende von get() aufgerufen werden, sofern sie definiert sind.

Folge: Beim Aufruf von $tpl(tplID) passiert noch nichts besonderes, außer das ein Objekt zu Rückgabe gebildet wird. Der Aufruf von bindTo() auf dem Objekt stößt nun den Request an, welcher danach das echte bindTo ausführt!

So. Das wollte ich loswerden , vielleicht hilft es ja irgendwem oder animiert Leute JavaScript zu lernen…

Bei echtem Verwendungsinteresse des Codes einfach Mail an mich.

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”. Komposition ist schon ein wenig schwieriger. 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.

PHP und Python unterscheiden sich stark, daher wird dieser Vergleich vor allem auf die Verwendbarkeit für ein Browsergame abzielen.

Python lässt sich, im Gegensatz zu PHP, welche eine pure Websprache ist, für jegliche Anwendung verwenden. PHP wird sehr gerne für Websiten verwendet, der Code ist schnell geschrieben, besondere Strukturen würden zwar nicht schaden, sind aber nicht von Nöten, weshalb kaum einer sich wirklich Mühe gibt. Dementsprechend ist auch der Ruf sehr schlecht. Es gibt viel zu viel Spaghetticode, allein UGamela war ein Beweis.

Ich persöhnlich habe mich sehr mit OOP und Designpatterns angefreundet und überzeugt ein gut strukturiertes stabiles Spielgerüst zu bauen. Es ist eindeutig ein Anreiz einmal OpenSource-Code mit Qualität aufzubauen, es wird viel zu viel geklagt wenn man sich mal umhört. Auch da geht der Abscheu zu PHP mit einher. Wenn man in höheren Kreisen erzählt man schreibe ein Browsergame in PHP wird man komisch angesehn. Zu Recht, denn PHP scheint denkbar ungeeignet:

Ein Browsergame ist mit nichts im Web wirklich vergleichbar und trotzdem versucht man es in einer Scriptsprache zu schreiben, die denkbar ungeeignet ist, schon allein aufgrund Performance. Um den Überblick im Spiel halten zu können (Wartbarkeit) und auch mal kurz neue Features einzufügen oder zu testen (Erweiterbarkeit & Flexibilität) muss der Code gut strukturiert sein, sonst wird das nach kürzester Zeit chaotisch, wenn er es nicht sowieso schon war.

Noch ein paar weitere Dinge die ich für das Spiel brauche:

1. Eine einfache Sprache, denn das Spiel soll möglichst von jedem erweitert werden können
2. Verfügbarkeit auf Webservern, evtl. Webspaces und wenig Installationsaufwand
3. Wahrscheinlich ein CMS oder Framework, das mir Funktionen zur Userverwaltung abnimmt

1) Bieten PHP und Python beide, mir scheint Python sogar noch einfacher durch das Wegfallen der Klammern und die automatische Einrückung.

2) Hier schlägt PHP eindeutig Python, es ist quasi überall verfügbar, Standard.

3) In PHP sowie auch Python vorhanden, den PHP Frameworks wird aber allen keine besonders gute Performance zugesprochen.

Allgemeines Fazit:

PHP muss nicht so schlecht sein, wie alle sagen. Mit PHP lassen sich auch größere Projekte verwirklichen, aber dafür gedacht ist es weniger. Für kleine Sites ohne größeren serverseitigen Rechenaufwand ist es gut geeignet und auch überschaubar. Mit PHPs OOP lässt sich etwas anfangen, aber die Vorzüge echter objekt orientierter Sprachen bietet es nicht. Am Ruf darf man sich dann nicht stören.

Python sollte verwendet werden wenn OOP von belang ist, damit hebt es sich am stärksten von PHP ab. Wenn auf eurem Webspace Python verfügbar ist, dann kann ich nur dazu animieren das einmal auszuprobieren!

Mein Fazit:

Python ist denkbar besser geeignet, vor allem weil ich mir soviel Struktur wünsche. Ich freue micht jetzt schon auf den sauberen Code, habe die Semikolons und Klammern satt. Ein einfacher (billig) Webspace ist sowieso denkbar ungeeignet für ein Browsergame. PostgreSQL wird hervorragend passen, das unterstützt sogar innerhalb Python Aufrufe (Ersatz für die MySQL Procedures). In wieweit ich ein Framework wie Zope, Django oder Pylons zur Hand nehme steht noch nicht fest.

Ich möchte hiermit alle UGamela Interessierten dazu auffordern einmal in Python hineinzuschnuppern, der Aufwand könnte sich lohnen!

Es gibt in PHP zwei Typen von Objektreferenzen, auch wenn es keine Dokumentation dazu gibt (Wer eine findet bitte sagen..!).

Im Handbuch steht nur: Objekte werden immer als Referenz übergeben

Das stimmt natürlich, nur ist es nicht ganz so einfach. Das Problem fällt allerdings erst auf, wenn man Objekte kontrolliert zerstören will.

$obj = NULL; # (1)

Sollte ein Objekt zerstören, wie unset(). Doch was wenn man vorher

$obj2 = $obj;

gemacht hat? Plötzlich zerstört der erste Befehl (1) nichtmehr, er setzt nur die erste Variable auf NULL. Nun das selbe ein bischen verändert:

$obj2 = &$obj; # & für Referenz sollte eigentlich nicht nötig sein

(1) Führt nun dazu, dass beide Variablen NULL sind. Huch?

Diese Referenzen heißen entweder hard/soft oder echt/unecht, wie auch immer.

Die letzten Tage bin ich aber endlich darauf gekommen, wofür man diese Interfaces in PHP verwenden kann.

Zuerst einmal: Was ist so ein Interface?

Interfaces sind Klassen, die bestimmte Funktionen vorbestimmen. Die Funktionen bilden dann eine Schnittstelle, also eine bestimmte Möglichkeit von anderen Objekten angesprochen zu werden. Im Gegensatz zu anderen Klassen werden Schnittstellen implementiert (“implements”). Dadurch kann eine Klasse mehrere Schnittstellen haben, aber nur von einer einzigen normalen Klasse abstammen.

Man muss also nur die Schnittstelle kennen, um die Klasse verwenden zu können, die sie implementiert. Anders gesagt, man kann die Klasse so verwenden wie man die Schnittstelle als Klasse verwenden würde.

Sehr konkrete Beispiele liefert PHP selbst mit einigen Schnittstellen:

ArrayAcces: Die Objekte einer Klasse lassen sich wie Arrays ansprechen.
Iterator: Die Eigentschaften einer Objekts lassen sich iterieren, also auf eine bestimmte Weise durchlaufen.

Interfaces lassen sich aber auch noch weit abstrakter verwenden:

Ich schreibe ein Interface Datenbankverbindung, das ich aus praktischen Gründen dokumentiere. Ich weise nochmal darauf hin, dass dieses Interfaces keinen Programmcode enthält, es gibt nur Struktur vor.

Danach schreibe ich einen Dekorierer für meine mysqli Klasse und achte derweil auch etwas darauf, wie PDO aufgebaut ist, denn wahrscheinlich wird das eine weitere mögliche Datenbankverbindung (->Interfacename…) mysqli wird etwas zurechtgebogen und erweitert.

Resultat: Ich kann verschiedene Datenbankklassen nach ein paar Anpassungen verwenden. Ich benutze mysqli, weil es anscheinend die schnellste ist, was MySQL angeht. Letztlich verwende ich Typehints auf “Datanbankverbindung” und Autovervollständigung für das Interface, welches ich dokumentiert (phpDoc, Zend Studio) habe.

Ich hoffe, ich habe es etwas anschaulicher erklärt, als es das Handbuch tut. Ich erinnere nocheinmal daran, dass dies keineswegs einfach ist und ich selbst lange gebraucht habe es zu verstehen.