Mit Helper-Klassen ein fluent interface bzw. method chaining erstellen

[generic]

Moin DP,

ich hab ein weiteres Video online.

In meiner Domäne möchte ich ein kompliziertes Kunde-Objekt erzeugen. Dazu nutze ich in dem Video ein Fluent interface bzw. Method chaining.

Damit ich die Logik nicht in meinen Transport-Objekten halten muss, verwende ich zusätzlich eine Helper-Klasse. Mit diesen können beliebige Klassen erweitert werden, ohne dessen Quelltext zu verändern.

Punkte von dem Video sind:
- was ist method-chaining / fluent
- es gibt Helper-Klassen wo man was erweitern kann, was ggf. nicht vererbt werden kann oder soll

Das Video befindet sich hier:
https://youtu.be/XXrFtNa1UIE

Quelltext:
fluent.7z

[stahli]

Danke!

Solche Videos finde ich immer interessant (auch wenn ich grundsätzlich kein Fan von fluent interfaces bin).

[generic]

Ich bin da zwiespaltig in der Meinung.

Schließlich muss man das Interface implementieren, was Zusatz Aufwand ist. Entgegen steht halt die gute Leserlichkeit.

Aktuell ist das aber ein Trend in viele Projekten und Libs. Gerade im C# Bereich findet man das immer mehr.
In den Teams wo ich arbeite werden meistens Mocks damit gebaut.
Für API setzen wir das eher selten ein.

[Rollo62]

Danke für das Video.
Also ich setze das sehr gerne ein, kann mir guter Syntax Einiges verbessern.
Das Problem sind meist die guten Bezeichner zu finden.
Ich arbeite auch gern mit _Begin, _End Strukturen, um Teilbereiche der Definitionen sauber zu kapseln.
Vorteil ist auch das AutoComplete damit super klarkommt, und weniger Fehler entstehen.

[Stevie]

Ein großer Vorteil von Fluent API wurde überhaupt nicht erwähnt, weswegen sie auch gern für DSL genutzt wird:
die Möglichkeit, eine Art Grammatik zu definieren (z.B. wir das bei den meisten Mocking Bibliotheken gemacht, die Fluent API nutzen).

Man liefert in solchen Fällen dann nicht immer denselben Typen zurück, sondern spezielle Fluent API Typen, die immer nur die richtigen Methoden anbieten.

Persönlich find ich ja, dass das Builder Pattern mit Fluent API statt Eigenschaften setzen ein bisschen nach Java stinkt
Das hier gezeigte liefert leider auch keinen Mehrwert gegenüber dem herkömmlichen Weg, die Eigenschaften zu setzen.