Wobei das eben wirklich extrem von der Anforderung abhängt – ich kann mir wundervoll auch eine Exception vorstellen, die entsprechend abgefangen bzw. erklärt auch eine Lösung wäre. Da allerdings komme ich wieder zu meinem Problem mit den nicht vorhandenen Checked-Exceptions, weil die API bei .NET eben nirgendwo sagt, dass hier eine Exception kommen könnte. Das wiederum wäre dann ein Verstoß gegen die Vorhersagbarkeit von Code-Verhalten und würde erfordern, dass ich außerhalb des Layers über Interna bescheid wüsste (oder mir die Exception-Annotierung der Methode ansehen müsste). Ich wäre also nicht gezwungen, mit einer Exception zu rechnen. Fände ich insofern wieder inkonsequent.

ich habe mich im Zuge meiner Bachelorarbeit mit dem Thema der Fluent Interfaces etwas intensiver beschäftigt. Die Art wie du das Fluent Interface verwendet hast findet man ganz häufig und ist sicher auch am schnellsten implementiert. Aber man kann mit Fluent Interfaces noch viel mehr machen. Man kann Schnittstellen bauen die sich beinah von selbst erklären und kaum falsch verwendet werden können. Was ist zum Beispiel, wenn du möchtest, dass die Methoden in einer bestimmten Reihenfolge aufgerufen werden oder dass bestimmte Methoden immer aufgerufen werden?

Du könntest so z.B. nie einen Satz erzwingen der in etwa so aussieht:

polyogn().with(punkt(1,1)).and(punkt(2,2);

Damit der Benutzer des Fluent Interface nach “polygon()” nur “with()” aufrufen kann, müssen wir hier einen Typen zurück liefern, der auch nur die Methode bereitstellt. Das gleiche gilt auch für “with” und “and”. Man erstellt so einer Art Geflecht von Typen. Bei größeren Fluent Interfaces ist das natürlich sehr aufwändig. Darum habe ich einen Tool gebaut mit dem man Fluent Interfaces in Form eines Diagrammes erstellen kann aus dem dann der nötige Code generiert wird. Zwar kann derzeit nur Java-Code generiert werden aber es ist kein Problem das ganze auch für C# oder ähnliches anzupassen. Das geht sogar relativ schnell.

Unter <a href="http://www.fluent-interfaces.com"http://www.fluent-interfaces.com findet ihr mehr.

Hi,

ich habe mich im Zuge meiner Bachelorarbeit mit dem Thema beschäftigt. Das Prinzip nach dem du hier Fluent Interfaces beschrieben hast kann man noch so erweitern, dass diese nicht nur als Konfigurator-Objekt verwendet werden können. Das eigentlich schöne an einem Fluent Interface ist ja, dass es sich so gut wie selbst erklärt. Man kann sofort ohne Dokumentation erkennen wofür die einzelnen Parameter da sind. Aber was wenn man vielleicht möchte, dass die Methoden nur in einer bestimmten Reihenfolge aufgerufen werden dürfen oder ganz bestimmte Methoden immer aufgerufen werden müssen? Das würde dem Benutzer eines Fluent Interfaces davor bewahren, dass Fluent Interface falsch zu benutzen. Aber ein entsprechendes Fluent Interface zu erstellen ist wesentlich aufwändiger. Und genau hier setzt meine Bachelorarbeit an. Ich habe versucht das Erstellen von Fluent Interfaces so weit wie möglich zu erleichtern. Mit Hilfe eines Modellers ist es nun möglich Fluent Interfaces in Diagrammen zu modellieren aus denen dann direkt der Programm-Code generiert werden kann.

Schaut mal einfach unter: http://www.fluent-interfaces.com

Zwar wird zur Zeit nur Java-Code generiert, aber das ganze ist so konzipiert, dass man schnell auf eine andere Sprache umsteigen kann.

Grüße
Philipp

Die Verwendung von “Set” bei den Methoden-Namen ist meines Erachtens unnötig und stört auch den Lesefluss.

config.Text(“Hallo, Welt”).Height(20).Width(40).Execute();

Desweiteren wäre ein kleiner Hinweis auf ein

return this;

der bei jeder Fluent-Methoden Implementierung notwendig ist hilfreich.

Im Grunde genommen stimme ich Dir zu. Allerdings sehe ich es etwas gelassener, da ich mein ExceptionHandling, wie so vieles andere, was mir die letzten Jahre fehlte, schon lange selbst so gebaut habe, dass es meinen Ansprüchen genügt Von daher ist mir das relativ wurscht, ob sich das kompilieren lässt oder nicht. Natürlich wäre es wünschenswert aber ich kann die Argumente, ehrlich gesagt, gut nachvollziehen. Viele machen sich wenig Gedanken um Exceptions und deren Behandlung, da wird einfach Catch e As Exception -> Do nothing geschrieben und gut ist. Nicht schön, aber effektiv (und sorgt für Arbeit, wenn die Anwendung dann irgendwann mal nicht mehr rund läuft und sie einen Spezialisten brauchen, der schaut, warum das denn so ist