> [!warning] #antipattern > Outside of few well-defined cases (ex: [[ORM]]s), I believe that fluent interfaces are antipattern. [Fluent Interface](https://en.wikipedia.org/wiki/Fluent_interface) ```csharp IEnumerable<string> query = translations .Where(t => t.Key.Contains("a")) .OrderBy(t => t.Value.Length) .Select(t => t.Value.ToUpper()); ``` This is quite popular in [[Java]] and [[Csharp|C#]]. Why? - Workaround for keyword arguments. - Ability to write DSLs - Ability to convey "pipelining" semantics.] Is this still popular? no. - [[Keyword Arguments]] made this unnecessary. - OOP in general, but especially the fluent interface is incompatible with code pruning techniques. [[ESM & CJS Modules#Tree Shaking|Tree Shaking]] is a major topic in JavaScript which discourages fluent interfaces. ## "keyword argument" semantic See the following code: ```python # basic NewPoint(5, 14); # fluent api NewPointBuilder().setX(5).setY(14).build() # keyword arguments NewPoint(x=5, y=14) # map as a keyword argument NewPoint({"x":5, "y":14}) ``` As the number of method parameters increase (especially if they share types), it becomes unclear how they are mapped to each other. Moreover, If a parameter is optional, then you either need to resort to [[Function Overloading]] or perform an extensive [[Refactoring]]. Fluent builders allow you to avoid this. However, for this case, [[Keyword Arguments]] can play the same role, but built into the language. Parameter mapping ambiguity is less of a concern; Keyword arguments also allow one to add an optional argument gracefully. ## DSL semantic Many libraries like [[Guice]] used the fluent interface to define DSLs. ```java bind(Printer.class).toInstance(consolePrinter); ``` # Use Case: [[ORM]] Many ORMs use the fluent interface to construct queries.