Fünf Jahre ist es her, dass ich das letzte Mal einen Artikel veröffentlicht habe. Man kommt ja zu nix mehr neben der Arbeit und dem Laufen. Vor einem halben Jahr hatte ich aber mal wieder Lust aufs Artikelschreiben, und das Ergebnis ist jetzt da, in der ix 05/2008 auf Seite 126: Entwurfsmuster: Flexibel programmieren mit dem Fluent Interface.[Update 13.01.
In dem viereinhalbseitigen Artikel entwickle ich schrittweise einen Builder (im Artikel "Erbauer" genannt) zu einem sog. Fluent Builder (im Artikel schreibe ich vom "Flüssigen Erbauer"), also einem Builder mit einem Fluent Interface. Der hat dann einige Vorteile, weil man z.B. eine Grammatik vorgeben kann und so eine domänenspezifische Sprache (DSL) ermöglicht. Dadurch wiederum wird der Builder sehr flexibel verwendbar, ohne dabei Inkonsistenzen zu erzeugen.
Die Bezeichnung Fluent Builder ist nur logisch, wenn man ein Fluent Interface mit einem Builder kreuzt; es haben schon andere ihr Ergebnis so bezeichnet. Allerdings habe ich da nicht geklaut: Der Artikel ist im September 2007 entstanden, wohingegen das erste Auftauchen eines Fluent Builders (der auch das meint, was er bezeichnet) von Dezember 2007 her datiert. Dort wird allerdings das gebaut, was ich in dem Artikel als "Zartschmelzende API" bezeichne und den Evolutionsschritt 2 von 4 kennzeichnet. Im Artikel gehe ich also noch etwas weiter in der Materie.
Der Fluent Builder ist in einem Projekt bei einem großen deutschen Versicherungskonzern entstanden. Dort hatte ich alle vier Entwicklungsstadien, die im Artikel beschrieben sind, durchexerziert, sehr zum Leidwesen meiner Kollegen dort. Auf deren Drängen bei meinen ersten flüssigen Gehversuchen ("Bernd, das ist inkonsistent, da sind die Verantwortungen nicht getrennt, das ist B****hit!") bin ich überhaupt erst soweit gekommen. Und als ich dann endlich soweit war, dass ich auf so ziemlich alle Fragen zur Flüssigen Entwicklung Antworten geben konnte - da wollte ich das nicht jedesmal neu erzählen und hab's aufgeschrieben. "Zweifel nähren das Denkvermögen" (Peter Schumacher), und daher ist dann irgendwann jener Artikel in der ix draus geworden. Speziellen Dank also an Matthias und Andreas für fruchtbare Reibereien.
Danke, Jorina, Stefan, Urs und Matthias, fürs Reviewen. Dank auch an meine Redakteurin Kersten Auel für die sehr gute Betreuung.
Errata
12.05.2008: In Listing 4 müsste es in der ersten Zeile statt
public class AbschnittWertZuStelleDescriptor {lauten
public class AbschnittWertZuStelleDescriptor<Rueckgabe> {Danke an Carsten Siedentop für sein Feedback.
Hallo,
AntwortenLöschenich habe mich im Zuge meiner Bachelorarbeit sehr intensiv mit Fluent Interfaces auseinander gesetzt. Als einer der größten Hindernisse ein solches zu erstellen, sehe ich vor allen Dingen die umständliche Implementierung. Gerade wenn man komplexere Grammatiken abbilden will wird die Pflege auf Codeebene sehr schwer. Darum habe ich versucht die Realisierung von Fluent Interfaces auf eine abstraktere, intuitivere Ebene zu heben. So ist es nun möglich ein Fluent Interface in Form eines Diagramms zu modellieren. Aus diesem Modell heraus wird dann der entsprechende Java-Code (eine andere Programmiersprache ist natürlich auch denkbar) generiert der dann nur noch durch wenigen manuellen Code angereichert werden muss. Für ein Beispiel-Projekt konnte ich so fast 95% des nötigen Codes aus einem Modell automatisch generieren lassen. Das zeigt wieviel Programmcode eigentlich dafür notwendig ist um überhaupt die Grammatik eines Fluent Interfaces zu erstellen. Unter http://www.fluent-interfaces.com findet man bereits ein wenig Material zu meiner Lösung.
Der Artikel zum Entwurfsmuster Fluent Builder ist wirklich eine hervorragende Grundlage für das Thema. Jedem der sich für Fluent Interfaces interessiert empfehle ich diesen Artikel.