Fluent Interface or Fluent Style has been defined for some time. It is something specific to OOP due to the way that method calls are being made (you are calling the method on an object). A subset, or standard way of doing Fluent style is through the use of method chaining.
As a C# developer, the first time I found the term Fluent Style was with the introduction of LINQ on .Net 3.5
You can see that upon TestObjects (a List, which inherits from IEnumerable) we do an operation, Where, that returns an IEnumerable, upon which we do another operation, First, that will return a single object.
Of course, method chaining and fluent style have been present from the beginning in C#. Due to the String class being inmutable, you could chain method calls if you wanted to do multiple operations to a string.
You can do this on other OO languages
As you can see, the rule that needs to be followed is that you must return the next object (on this case self) that is going to have a method called.
You can even combine returning different objects to chain several method calls.
But what about damaging a monster?
This is where the chain breaks. getDamage() returns an integer, and there is no way to chain that result into monster. This is due to the way that you need to return the object unto which you are going to act next.
This idea of chaining works sligthly different on FP languages.
Really, what I’m doing here is just accessing members of structures and returning them. If you consider each member like a get property you actually get the same behaviour as with the Ruby code.
But what about that proposition with monster? How do I achieve that?
Enter the pipe operator: |> (on Elixir and F#, Clojure has the reader macros -> and -»)
What the pipe operator is doing in this case is pass the result on the left as the first parameter to the function on the right.
The pipe operator becomes the abilitator of chaining. While in OOP languages you do a call on the return value (the context), on FP languages you pass the return value (the context) as parameter to the next function. With this behaviour, what you can achieve is to chain far more easily.
Looking at the chaining of strings, for example, we get this:
Of course, on FP working with lists/sequences is the most natural thing to do.
What you see there is that the chaining what it does is make you follow the transformations of your data in the order in which is processed (paraphrasing from a Hacker News commenter). It is quite similar to what you can achieve using LINQ on C# (which operates on IEnumerables).
For FP languages, compared to OOP, though, I think that the biggest difference is the one expressed before: instead of having to return an object to make the next call, the return becomes a parameter to the next call. It allows for more flexibility on chaining calls.
Let’s going to look back at the player/weapon duo from before, but with some more code in it.
On Demonstration.demo we have the line |> Weapon.do_random_damage.
On Demonstration2.demo we have the line |> Player.remove_weapon.
Because the result of the previous call is passed as parameter, it does ensue that is more easy to change which one is the next call. Trying to achieve the same thing with OO will led to a badly shared interface, most probably.