Fluent Interfaces: Sinnvoll?
Ich hatte Fluent Interfaces mal in einem Blog gelesen und hatte es seit dem auf meinem Zettel stehen, das mal genauer anzusehen.
Was ist das eigentlich? Wikipedia weiß es natürlich.
Sucht man bei Google danach findet man Blogs mit Einträgen von 2006/2007…sind Fluent Interfaces schon tot? Vielleicht!
Einige Beispiele:
1 | IConfigurationFluent config = |
Das schreit einfach nach dem Object Initializer von C#! In etwa so:
1 | IConfiguration config = new Configuration |
Dann spart mach sich das zusätzliche “return this” in der Implementierung.
Ok, dann hat Troy Demonbreun folgendes Beispiel:
1 | order |
Das sieht an sich ja ganz nett aus, allerdings hat seine Implementierung den “Fehler”, dass IncludeItem() den Kontext von Order auf OrderItem ändert. Nach meinem Verständnis von Fluent Interfaces müsste aber folgendes möglich sein (geht bei ihm nicht):
1 | order |
Und als drittes Beispiel hab ich folgendes, leicht komplexes Konstrukt gefunden:
1 | EventComponent planningMeeting = |
Hier kann ich schon etwas verstehen, warum Fluent Interfaces (=FIs) sexy sein könnten. Aber zuerst muss ich hier auch sofort wieder an Object Initializer und Collection Initializer denken (Nein, ich bau das jetzt nicht um :-P ) und dann hab ich da noch einen letzten Punkt zu: Man kann FIs nur einsetzen, wenn man zu einem Zeitpunkt bereits alles weiß zu dem Objekt, was man erstellen will. Das ist an sich ja nicht schlecht, aber wie kommt denn die Liste der Attendants da rein? Doch meistens mit foreach und das geht nicht in dieser Kette von Aufrufen.
Ach und noch ein allerletzter Punkt: In diesem Ansatz muss ich viel Schmalz darauf verbraten, wann eine Methode Sinn macht:
1 | Attendants( … ).Except.Minutes.WithPriority(1); //?! |
Fazit:
[x] Ich hab mir Fluent Interfaces angesehen
[x] Ich weiß keinen guten Fall, wann das Ganze wirklich Sinn macht