imported>SchlurcherBot: Bot: http → https

2025-07-09T11:19:12Z

Bot: http → https

Neue Seite

'''Fluent Interfaces'''<ref name="Fluent Interfaces">Martin Fowler: [https://www.martinfowler.com/bliki/FluentInterface.html ''Fluent Interfaces''.] Bliki-Eintrag</ref> (deutsch oft übersetzt mit: „flüssige Schnittstellen“, treffender etwa: „sprechende Schnittstellen“) sind ein Konzept für [[Programmierschnittstelle]]n in der Software-Entwicklung, bei dessen Befolgung man beinahe in Form von Sätzen natürlicher Sprache programmieren kann. Der danach verfasste Programmcode ist gut lesbar und erleichtert das Verständnis des Programms.

Schnittstellen werden oft falsch verwendet. Fluent Interfaces können zu ihrer richtigen Verwendung anhalten, indem für sie eine [[Grammatik]] gewählt wird, die von falschen Verwendungen erkennbar verletzt wird. Es gibt zwei Arten, solche „sprechende Schnittstellen“ zu realisieren, mittels Method Chaining (Methodenketten) oder mittels Nested Functions (eingebetteten Funktionen).

== Grundlagen ==
Als Begründer des Konzepts ''Fluent Interfaces'' gelten Eric Evans und [[Martin Fowler]]. Bei der Beispielimplementierung des [[Entwurfsmuster]]s [[Specification]]<ref name="Specification">[https://martinfowler.com/apsupp/spec.pdf Specifications] (PDF; 79 kB)</ref> erfanden sie das Konzept, neue Objekte mit Hilfe von Methodenketten auf sprechende Weise zu erstellen.

<syntaxhighlight lang="java">
Specification colorSpec = new ColorSpecification();
Specification lengthSpec = new LengthSpecification();
if(colorSpec.and(lengthSpec).isSatisfiedBy(obj)) {
...
}
</syntaxhighlight>

Im oberen Beispiel steht in der Bedingung der if-Anweisung ganz ausdrücklich, dass das Objekt ''obj'' auf beide Bedingungen getestet wird. Ein weiteres Beispiel ist das sprechende Erstellen eines Datums.

<syntaxhighlight lang="java">
DateFactory.newDate().year(2009).month(2).day(7);
</syntaxhighlight>

Anders als bei der Verwendung eines [[Konstruktor]]s, in dem die Bedeutung der drei numerischen Werte versteckt durch ihre Position im Aufruf gegeben wäre, sieht man hier durch die vorstehenden Methodennamen ausdrücklich, welche Bedeutung die einzelnen Werte haben sollen. Außerdem kann der Entwickler einer solchen Schnittstelle die Reihenfolge einschränken, in der die Methoden aufgerufen werden dürfen. Damit können etwa Methodenaufrufe, die mehrere Parameter erwarten, wesentlich verständlicher geschrieben werden.

Besonders in Evans’ [[Domain-driven Design]] spielen Fluent Interfaces eine große Rolle, denn sie dienen ihm dazu, spezifische Eigenschaften aus einer Domäne explizit im Programmcode auszudrücken. Fluent Interfaces gehören damit zu den sogenannten [[Interne Domänenspezifische Sprache|Internen Domänenspezifischen Sprachen]],<ref name="Interne Domänenspezifische Sprachen">Martin Fowler: [https://www.martinfowler.com/bliki/DomainSpecificLanguage.html ''Domain Specific Language''.] Bliki-Eintrag</ref> auch als Eingebettete Sprache bezeichnet.<ref name="Evolving an Embedded Domain-Specific Language in Java">[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.95.3176&rep=rep1&type=pdf ''Evolving an Embedded Domain-Specific Language in Java''.] (PDF)</ref> Es sind [[Domänenspezifische Sprache]]n, die in der Syntax einer [[Programmiersprache]] realisiert sind.

== Implementierung ==
=== Naiv ohne Grammatik ===
Die Beispielimplementierung von Evans und Fowler für das Entwurfsmuster Specifications war sehr schlicht gehalten. Um eine Methodenkette mit ''and'' wie oben zu ermöglichen, wurde dem [[Interface]] "Specification" nur die neue Methode ''and()'' hinzugefügt.

<syntaxhighlight lang="java">
public interface Specification {

Specification and(Specification spec);

boolean isSatisfiedBy(Object obj);

}
</syntaxhighlight>

Bei Aufruf von ''and()'' liefert also jede Specification eine weitere, die ihrerseits wiederum aus einem Aufruf der Methode ''and()'' stammen kann. Durch diesen naiven Ansatz wird jedoch die Implementierung von Typen um Funktionalitäten angereichert, die ihrem eigentlichen Zweck fernliegen. Der Hauptnachteil ist jedoch, dass Methoden in ganz beliebiger Reihenfolge verkettet werden dürfen.

=== Mit Grammatik ===
Häufig spielt die Reihenfolge, in der die Methoden einer Methodenkette aneinander gereiht werden dürfen, eine große Rolle. Das folgende Beispiel zeigt die Verwendung eines Fluent Interfaces, das einem Objekt vom Typ ''Date'' einige Tage und Stunden hinzufügt.

<syntaxhighlight lang="java">
Date date = CalendarUtils
.add(5).days()
.add(10).hours()
.to(date);
</syntaxhighlight>

Würde man, wie im naiven Ansatz, mit jedem Aufruf einer Methode immer den gleichen Typ zurückliefern, dann kann der „Satz“ vorzeitig oder falsch beendet werden, indem nicht alle obligatorischen „Satzglieder“ oder manche mehrfach verkettet werden. Damit die solches ausschließende [[Grammatik]] erzwungen wird, muss also jeder Aufruf einer Methode einen anderen Typ zurückgegeben, der nämlich nur die jetzt noch erlaubten Folge-Methoden bereithält. Im folgenden Beispiel sieht man, wie der Aufruf der Methode ''newDate()'' von ''DateUtils'' zur Rückgabe eines ''Mediators'' führt. Dieser hält dann die Folge-Methode ''add'' bereit. Der Aufruf der Methode ''add'' wiederum führt ebenfalls zur Rückgabe eines neuen ''Mediator'' usw.

<syntaxhighlight lang="java">
public class DateUtils {
public static Mediator newDate() {
...
}
}

public class Mediator {
public Mediator2 add(int i) {
...
}
}

public class Mediator2 {
public Mediator3 days() {
...
}
}

...
// possible sentence
DateUtils.newDate().add(5).days(). ...

</syntaxhighlight>

Bernd Schiffer bezeichnet diese ''Mediatoren'' auch als ''Deskriptoren''.<ref name="Flüssiger Erbauer">[https://www.heise.de/developer/artikel/Flexibel-programmieren-mit-dem-Fluent-Interface-227052.html Flüssiger Erbauer]</ref> Mit obigem Beispiel wird also eine [[Grammatik]] realisiert, die genau vorgibt, in welcher Abfolge die Methoden aufgerufen werden können. Außerdem liefert die Methodenkette solange kein gewünschtes Objekt vom Typ Date, wie sie noch nicht vollständig ist. Deshalb zeigen sich bei Verwendung einer so implementierten Klasse ''DateUtils'' Fehler schon bei der Kompilierung des anwendenden Programms und nicht erst zur Laufzeit.

== Vorteile ==
Die Vorteile liegen in der leichteren Entwicklung nutzender Programme und der besseren Lesbarkeit des dazu verfassten Programmcodes.
* Fluent Interfaces können einem natürlich-sprachlichen Satz sehr nahekommen. Damit muss man nur wenig zusätzlich kommentieren.
* Durch ein satzähnliches Fluent Interface und den damit insinuierten erlaubten Satzaufbau bekommt der Benutzer klarere Vorstellungen über die angebotenen Funktionalitäten und ihren möglichen Gebrauch.
* Eine [[Integrierte Entwicklungsumgebung|Entwicklungsumgebung]] mit Autovervollständigung wie etwa [[Eclipse (IDE)|Eclipse]] zeigt an, welche nächsten Methoden aufgerufen werden können.

== Nachteile ==
Die Nachteile liegen im Aufwand für das Fluent Interface selbst und der erschwerten Entwicklung von nutzenden Programmen.
* Die Realisierung einer [[Grammatik]] für Fluent Interface ist sehr aufwendig und das notwendige Netzwerk von Mediatoren wird schnell unübersichtlich. Zudem lässt sich auf deren Ebene schwer nachvollziehen, welche Satzkonstruktionen möglich sind. Durch Modellierung von Fluent Interfaces in Form von Diagrammen wird versucht, diesen Nachteil zu meiden. Es wird dazu aus einem Modell der notwendige Mediator-Code automatisch generiert, sodass es nur noch nötig ist, das Verhalten des Fluent Interfaces selbst zu implementieren.
* Eine lange Kette von Methodenaufrufen auf derselben Zeile erschwert deren Debugging, da ein Callstack typischerweise nur die Zeile des Fehlers enthält, nicht aber die Spalte im Source-File. Das Gleiche gilt für die Zuordnung von Warnungen aus der statischen Codeanalyse. Außerdem lassen sich Haltepunkte oft nur auf vollständige Anweisungen setzen, nicht auf einzelne Methodenaufrufe darin.

== Einsatzmöglichkeiten ==
Fluent Interfaces werden für verschiedene Zwecke eingesetzt. Im Vordergrund steht immer, explizit zu machen, was in einer Domäne verankert ist.

* Verpacken von Funktionalitäten
*: Wie oben dargestellt, können Fluent Interfaces bestehende Funktionalitäten verständlicher anbieten.
* Flüssiger Erbauer<ref name="Flüssiger Erbauer" />
*: Übertragung des Konzepts Fluent Interface auf das [[Entwurfsmuster]] [[Erbauer (Entwurfsmuster)|Erbauer]].
* Abbildung fremder Syntax
*: Mit Hilfe von Fluent Interfaces kann man im Programmcode auftretende [[Zeichenkette]]n etwa für interpretierte Sprachen wie z. B. [[SQL]], [[XPath]] oder [[Hibernate Query Language|HQL]] begrifflich leichter fasslich durch Aufrufe ersetzen.

== Hinweis ==
Einige Programmiersprachen unterstützen benamte Parameter, z. B. [[Smalltalk (Programmiersprache)|Smalltalk]] oder [[ABAP]]. Bei diesen ist das Konzept der '''Fluent Interface''' nicht sinnvoll, da die Methodenschnittstellen bereits durch die Eigenschaften der verwendeten Sprache sprechend sein müssen.

Beispiel Smalltalk:
<syntaxhighlight lang="smalltalk">
object param1:foo param2:bar
</syntaxhighlight>

Beispiel ABAP:
<syntaxhighlight lang="abap">
lo_object->myMethod(
iv_param1 = foo
iv_param2 = bar
).
</syntaxhighlight>

== Weblinks ==
* {{Internetquelle | url=https://www.martinfowler.com/bliki/FluentInterface.html | titel=FluentInterface | autor=Martin Fowler | datum=20. Dezember 2005 | zugriff=2012-03-06 | sprache=en }}
* {{Internetquelle | url=https://www.net-developers.de/blog/2010/02/05/php-verkettete-methoden-fluent-interface/ | titel=PHP: Verkettete Methoden / Fluent Interface | zugriff=2012-03-06 }}
* {{Internetquelle|url=http://tech.pro/tutorial/1187/creating-a-c-fluent-api|titel=Creating a C# Fluent API|sprache=en|kommentar=Erklärung von Fluent Interfaces in C# für Anfänger|datum=2013-04-09|zugriff=2013-04-14|autor=Khalid Abuhakmeh|hrsg=Tech.Pro}}
* {{Internetquelle|url=https://heinerkuecker.de/Fluent_Interface_Code_Generator_auf_Basis_einer_Grammatik.html|titel=Java-Fluent-Interface-Code-Generator auf Basis einer Grammatik|kommentar=Einfaches Java-Programm, welches auf Basis einer Grammatik den erforderlichen Code-Rahmen für ein Fluent Interface generiert|datum=2014-01-31|zugriff=2014-01-31|autor=Heiner Kücker}}

== Einzelnachweise ==
<references />

{{Navigationsleiste Entwurfsmuster}}

[[Kategorie:Schnittstelle (Software)]]
[[Kategorie:Entwurfsmuster]]
[[Kategorie:Softwaretechnik]]
[[Kategorie:Systems Engineering]]

Fluent Interface - Versionsgeschichte

imported>SchlurcherBot: Bot: http → https