ich habe mich in meiner Bachelorarbeit sehr intensiv mit Fluent Interfaces auseinander gesetzt. Wie schon in dem Artikel angedeutet wurde kann man ja das ganze soweit treiben, dass man ein Art Grammatik damit umsetzt. Das aber im Programmcode umzusetzen ist doch ziemlich umständlich und zu dem teilweise schlecht nachvollziehbar. Unter http://www.fluent-interfaces.com findet ihr dazu einiges an Material.

Um das Erstellen und Pflegen von solchen Schnittstellen wesentlich zu vereinfachen habe ich das ganze auf eine abstraktere Ebene gehoben. Man kann nun in Diagrammen Fluent Interfaces modellieren. Aus diesen Diagrammen die nichts weiter als Ketten von Aktionen darstellen, kann man dann automatisch den notwendigen Code generieren lassen. Für ein relativ komplexes Beispiel (ca. 4000 Zeilen Code) musst ich so nur noch rund 200 Zeilen selber schreiben. Und ich kann auf meinem Diagramm sofort erkennen welche Sätze man so zusammenbauen könnte.

Im übrigen sollte man das Method-Chaining soweit im Zaumhalten, das es eben noch lesbar ist. Zu lange verkettete Aufrufe oder im schlimmsten Fall verstecke und gekapselte Kettenaufrufe machen das Debuggen auf jeden Fall zur Hölle.

entscheide dich ob $duSowasSchreibst oder ob $du_sowas_schreibst und nimm das einheitlich für alles was kommt.

und zum thema call chaining: lesbarer wird der code zwar, aber debuggen (vor allem den code eines anderen) ist eine tiefe qual weil ich bei manchen funktionen zumindest eine boolche debug nachricht erhalten will. dafür muss ich aber zuerst die funktion editieren. von daher wirklich nur mit bedacht verwenden.