Fluent Interface
Geschrieben von Peter Rother • Mittwoch, 7. Oktober 2009 • Kategorie: Design PatternMittlerweile habe ich das Fluent Interface Pattern für mich gewinnen können. Anfangs sah ich die ganze Sache doch ein wenig skeptisch aber inzwischen könnte ich ohne diese und ein paar andere Pattern kaum noch arbeiten. Aber was sind eigentlich Fluent Interfaces?
Mit Hilfe eines Fluent Interfaces kann man Schnittstellen erstellen die sich fast von alleine erklären und die Benutzer "an die Hand" nehmen die benutzte Klasse wie gewünscht zu bedienen. Fluent Interfaces bieten die Möglichkeit Programmcode auf einfache Art und Weise zu benutzen. Mit ihrer Hilfe können Schnittstellen programmiert werden, die einfach und intuitiv benutzbar sind.
Ein Beispiel für eine Implementierung könnte zum Beispiel wie folgend aussehen (Das Beispiel ist übrigens nicht von mir, sondern aus dem JAVA Bereich und auf PHP portiert). Hier soll ein Datums Objekt erstellen werden an dem normaler Weise alle Daten an den Konstruktor übergeben werden
$date =new dateObject (2009, 10, 07, 13, 0, 0 );
result = $date->getTime();
Hier soll folgendes Datum erstellt werden "07.10.2009 13:00:00". Leider ist aus dem angegeben Beispiel nicht wirklich ersichtlich welcher Wert für welchen Typ des Datums steht. Man könnte hier natürlich für jeden Teil des Datums, eine neue Methode des Datums Objekts aufrufen und dieser den neuen Wert zuweisen. Den dadurch resultierenden Code kann sich glaube ich jeder Vorstellen. Er könnte zum Beispiel nachfolgend aussehen.
$date = new dateObject();
$date->year( 2009 );
$date->month( 10 ):
$date->day( 07 );
$date->hour( 13 );
$date->minute( 0 );
$date->second( 0 );
$outputDate = $date->createDate()
Wenn man auf viel Code steht sollte dies der richtige Weg sein, doch wie könnte dies in einem Fluent Interface aussehen?
$outputDate = dateObject::year( 2009 )->month( 10 )->day( 07 )->hour( 13 )->minute( 0 )->second( 0)->createDate();
Der Quelltext ist hier um einiges kleiner und man muss sich mit einer vernünftigen IDE mit Auto Vervollständigung nicht einmal in den Quelltext einlesen - wenn alle Methoden richtig deklariert sind - da die IDE alle verfügbaren Methoden anzeigen sollte. Wir haben hier also ein sinniges Method Chaining erstellt was ohne weiteres zu benutzen ist und uns mit wenig Code den gleichen Weg vorgibt wie im ersten Beispiel. Was hierbei natürlich zu beachten ist, ist das jede aufgerufene Methode eine Instance des aktuell verwendet Objekts zurück liefert. Ohne diese Instance kann verständlicher Weise nicht auf die nächste Methode zu gegriffen werden.
1 Kommentare
ein solches Fluent Interface wie du es im Beispiel zeigst sieht auf den ersten Blick einfach aus zu realisieren aber schaut man genauer hin wird es schon ein wenig schwieriger. Was ist wenn du den Aufruf einer Methode wie z.B. "year()" nur einmal zulassen willst. Andernfalls könnte der Benutzer des Fluent Interface die Methode mehrfach in der Methodenkette aufrufen was dazu führt, dass wir uns nicht mehr sicher sein können welcher der Aufrufe am Ende im Ergebnis landet. Das ist nur ein Beispiel von vielen.
Wie du bin ich der Meinung, dass dieses Pattern die Benutzung von APIs enorm vereinfachen kann. Aber nur dann, wenn das Fluent Interface die Autovervollständigung soweit nutzt, dass nur die Methoden angezeigt werden die zu einem bestimmten Punkt in der Methodenkette erlaubt sind. Um das zu ermöglichen, muss du nach jedem Methodenaufruf einen neuen Typen zurückliefern, der auch nur die entsprechenden Methoden anbietet. Wir benötigen also ein Netzwerk von Typen um eine Art Grammatik zu realisieren und das kann je nach Fluent Interface sehr aufwendig sein.
Für meine Bachelorarbeit habe ich mich damals sehr intensiv damit auseinander gesetzt und ein Plugin (für Eclipse) erstellt mit dem es möglich ist diese Netzwerke als Diagramme zu modellieren, um daraus sofort den nötigen Code generieren zu können. Damit vereinfacht man das Erstellen von Fluent Interfaces enorm.
Schau mal einfach unter http://www.fluent-interfaces.com nach.
Der Philipp
Kommentar schreiben