Willkommen zu einem neuen Eintrag der Reihe „Design Patterns in der Praxis“ – Thema heute ist das Fluent-Interface. Auf diesen Eintrag habe ich schon einige Zeit gewartet!

Nun, einige von euch haben das Fluent-Interface Pattern bestimmt schon mehrmals benutzt. Vor allem in Javascript und dessen Frameworks (jQuery, Prototype, …) wird dieses Pattern ausgiebig genutzt.

Das Fluent-Interface sieht vor, beliebig viele Methoden aneinander zu ketten:

// Ein Beispiel mit Hilfe von jQuery.
$('div#animate')
    .css({position:'absolute', top:0, left:0})
    .animate({top: '100px', left: '50px'}, 500)
    .append('Fertig animiert!')
    .click(function() {
        alert('Meldung!');
    });

Ihr seht, die verschiedenen Methoden wurden einfach nacheinander angehängt. Natürlich hätte man das ganze Skript auch folgendermaßen schreiben können:

// Ein Beispiel mit Hilfe von jQuery.
$('div#animate').css({position:'absolute', top:0, left:0});
$('div#animate').animate({top: '100px', left: '50px'}, 500);
$('div#animate').append('Fertig animiert!');
$('div#animate').click(function() {
    alert('Meldung!');
});

Ich bin mir nicht ganz sicher wie jQuery intern arbeitet, aber es könnte durchaus sein, das für jeden neuen Aufruf von $('div#animate') der DOM Baum durchlaufen wird, anstatt, wie im oberen Beispiel, direkt auf die Instanz des bereits gefundenen Objekts zuzugreifen. Das wäre jedenfalls ein nicht zu vernachlässigender Vorteil!

Das Ganze funktioniert natürlich auch wunderbar in PHP – Hier ein Beispiel aus dem Kohana Framework. Wir sehen die ORM Klasse in Aktion, mit der wir (sehr leserliche!) Datenbank-Abfragen formulieren können.

// Ein Beispiel mit Hilfe von Kohana.
$postings = ORM::factory('blog')
    ->where('author', '=', 'Leo')
    ->order_by('datum', 'DESC')
    ->limit(5)
    ->find_all();

Das Fluent-Interface Pattern bringt einige Vorteile und könnte dennoch in seiner Implementation kaum einfacher sein! Es muss einfach nur am Ende jeder Methode this (bzw. $this für PHP) zurückgeliefert werden. Das ist bei allen Setter-Methoden ohne weiteres möglich – bei Getter-Methoden eher nicht 😉

In einem meiner ersten Blog-Einträge habe ich eine „Benchmark“-Klasse veröffentlicht. Diese benutzt das Fluent-Interface Pattern, wie ihr im Benchmark zwischen einfachen und doppelten Anführungszeichen sehen könnt.

Liefert ihr also am Ende einer Methode die Instanz der eigenen Klasse zurück, so könnt ihr im Quelltext direkt die nächste Methode oder Variable ansprechen.

Wenn ihr euch den Wikipedia-Artikel durchlest werdet ihr feststellen, dass auch versucht wird eine gewisse „Grammatik“ mit dem Fluent-Interface Pattern abzubilden, doch das halte ich für nicht sehr sinnvoll. Natürlich ist das ganze dann wunderbar zu lesen und verstehen, doch der Aufwand der dahinter steckt ist unverhältnismäßig.

Dieses Pattern macht den Quellcode auch ohne eine echte Grammatik sehr viel einfacher zu lesen und zu verstehen – Sinnvolle Methoden-Namen natürlich vorausgesetzt 😉

Doch leider gibt es auch hier wieder ein paar Nachteile, die man bedenken muss:
So wird man schnell verleitet durch die „kurze“ Schreibweise mehrere Methoden hintereinander zu tippen (innerhalb einer Zeile) – Das ist nicht nur schlechter Stil sondern erschwert ggf. auch das Debuggen, da man häufig nur die Zeilen-Nummer als Hinweis auf den Fehler bekommt.

Ich persönlich benutze dieses Pattern sehr gerne! Es macht auf mich einen sauberen, schlanken und modernen Eindruck – Wie sieht es mit euch aus?

Mit diesen Worten möchte ich den heutigen Eintrag beenden und euch eine erfolgreiche restliche Woche wünschen! Ich bin derzeit mit mehreren Geburtstagen in der Familie beschäftigt, weshalb der Eintrag nicht ganz so ausführlich geworden ist wie erhofft…

Bis zum nächsten mal!