Talk:Fluent interface
From Wikipedia, the free encyclopedia
 | This article is rated Stub-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||
| ||||||||||||||||||
Returning this In Chained Methods
Under "Implementation": "... by having each method return the object to which it is attached, often referred to as this or self" Where did this criterion come from? It didn't appear in, for example, Fowler's original article, which instead explicitly said "You should choose your return type based on what you need to continue fluent action.", going on to use JMock as an example of a fluent library where the chained methods often return objects with different types from that which the methods were called on: those different types being more useful than simply finishing with "return this;" would have been. — Preceding unsigned comment added by 125.237.145.229 (talk) 02:23, 4 August 2024 (UTC)
Method Chaining vs Fluent Interface
According to the definition of fluent interface, this is not a fluent interface
const result = somestring.trim().padStart(10).replace('abc', 'def').padEnd(10);
A Fluent Interface chains on "this" which each method modifying the same object. The code above a new object is returned from each method, them a method of that new object is called. That is just method chaining.
To spread it out, to be a fluent interface the follow test has to pass
const a = somestring.trim();
const b = a.padStart(10);
const c = b.replace('abc', 'def');
const d = c.padEnd(10);
const isFluentInterface = (a === b && a === c && a === d); // isFluentInterface will be false here
An example that is a fluent interface
class Calc {
constructor(v) { this.v = v; }
add(v) { this.v += v; return this; }
subtract(v) { this.v -= v; return this; }
multiply(v) { this.v *= v; return this; }
divide(v) { this.v ;= v; return this; }
};
const result = (new Calc(1)).add(3).subtract(2).multiply(4).divide(3);
Applying the test above it passes
const a = new Calc(1);
const b = a.add(3);
const c = b.subtract(2);
const d = c.multiply(4);
const e = d.divide(3);
const isFluentInterface = (a === b && a === c && a === d && a === e); // isFluentInterface will be true here
Problem with the C# sample code
Hello!
1) I tried the C# sample code, but the compiler alerted 12 syntax errors. Please give a sample with runnable code.
2) The "fluent-interface-benefit" (short intuitive code) is not demonstrated very convincing. I would prefer to see something like:
IConfiguration config = ConfigurationFluent.Create().Color("blue").Height(1).Length(2).Depth(3);
or
IConfiguration config = ConfigurationFluent.CreateColored("blue").Height(1).Length(2).Depth(3);
(Create() or CreateColored() would be static methods, returning a new instance as an "entry-Point" into the fluent interface.
That is no really good Sample too, because C# 2008 provides the with-Keyword, so one could instantiate without fluent interface as well:
var config = new Configuration() with { Color = "blue", Height = 1, Length = 2, Depth = 3 };
3) A better sample would result in stuff like:
// List<SpecialItem> _SpecialItems = new List<SpecialItem>();
SpecialItem.CreateColored("blue").Height(1).Length(2).Depth(3).AddTo(_SpecialItems);
That would demonstrate, how fluent interface reduce nesting. Compare to:
// List<SpecialItem> _SpecialItems = new List<SpecialItem>();
_SpecialItems.Add(new SpecialItem() with { Color = "blue", Height = 1, Length = 2, Depth = 3 });
Unfortunately the benefit "help from Intellisense" (a fluent interface supports fluent writing code) cannot be shown in an article, or would you like to add screenshots?
ErfinderDesRades (talk) 11:11, 15 December 2008 (UTC)
IMO the published sample is garbage. Chaining in itself does not make for readability and the ALT.NET community is severely abusing mere chaining with this misunderstanding. There's nothing less readable about
myObject.SetValueX(1);
myObject.SetValueY(2);
than
myObject.SetValueX(1).SetValueY(2);
In my opinion, this actually makes it less readable because these are distinct statements that are being slurred together.
I agree that the samples from ErfinderDesRades are better. Jon (talk) 09:52, 30 September 2009 (UTC)
PHP sample
In the PHP sample, what is this part good for?
<?php
session_start();
error_reporting(E_ALL | E_USER_NOTICE);
require_once 'classes/Loader.php';
require_once 'config.php';
?>
Monad
Shouldn't a reference to monad be included somewhere in this article? Dave Sexton (talk) 08:43, 26 July 2010 (UTC)
Fluent Interface vs Method Chains
The article correctly states that a fluent interface entails more than just method chaining but then goes on to to show examples that solely use Method Chaining. This is misleading. The article and the examples could be improved to reflect a Fluent Interface' role in creating internal DSLs. This would make the distinction more clear. —Preceding unsigned comment added by 87.123.52.156 (talk) 08:46, 22 September 2010 (UTC)
- Same comment from my side. The C++ example in fact does implement a fluent interface, but not so the other examples. One correct example is much more worth than a dozen of examples whereof only one really illustrates the point. Since nothing happened since this comment from 2010 I am going to remove the other examples. --Chiccodoro (talk) 11:15, 7 September 2012 (UTC)
- The C++ example is also unnecessarily verbose. What about just deleting them all and adding a concise example in pseudo-code? As soon as you use a real language, people start getting all fanboyish and feel compelled to add their favorite one to the mix. — Preceding unsigned comment added by 82.9.176.129 (talk) 03:15, 18 December 2014 (UTC)