Humans are lazy and programmers are humans J . We like things which
are simplified and clean. So if you see the evolution of programming, we
initially started with functional programming, and evolved towards object
oriented programming.
So as functional programmers where we used to remember methods
and function names like “Add”, “Subtract”, “Multiply” and “Divide”, in OOP we
just need to remember class “Maths” and all functions just pop out when we
create the object of the class.
But as object oriented programmers we need to remember there
are two worlds in OOP, one who creates the class and second who consumes it by
creating the object.
So by following good OOP principles like abstraction,
encapsulation etc developer writes the below “Customer” class so that other
developers who consume this class should not feel it complicated.
public class Customer
{
private string _FullName;
public string FullName
{
get { return _FullName; }
set { _FullName = value; }
}
private DateTime _Dob;
public DateTime Dob
{
get { return _Dob; }
set { _Dob = value; }
}
private string _Address;
public string Address
{
get { return _Address; }
set { _Address = value; }
}
}
Now the consumer who want to consume our “Customer” class
will create the customer object , set properties and invoke methods. Below is the sample code for the same.
Customer customer = new
Customer();
customer.FullName =
"Shiv";
customer.Dob = Convert.ToDateTime("1/1/2008");
customer.Address =
"Mumbai";
Now let’s zoom on the above consumer code. Is it complicated?,
probably not if you are C# developer or a object oriented programmer.
But what if your consumer is a tester who really does understand
c# and would like to have more simplified interfaces to invoke your customer
class for UNIT testing purpose.
What if you are component seller and you would like to
surprise your component consumers with simplified interfaces. You would like to
stand different from your competitors.
Welcome to the concept of “Fluent interfaces”.
“Fluent interfaces simplify your object consumption code by making your code more simple, readable
and discoverable.”
So
if our component consumers can write object invocation code in simple English sentence
like below , that would “ROCK” right.
customer.NameOfCustomer("Shiv")
.Bornon("12/3/1075")
.StaysAt("Mumbai");
So now the next thing how to we implement “Fluent”
interfaces. That’s done by using “Method chaining”.
“Method chaining” is a
common technique where each method returns an object and all these methods can
be chained together to form a single statement.
So the above customer class we can wrap in another class (“CustomerFluent”)
which will implement method chaining and expose chained methods in a simplified
format.
So you can see in the below code methods “NameofCustomer” ,
“BornOn” accept input s and return backs “CustomerFluent” class.
public class CustomerFluent
{
private Customer obj = new Customer();
public CustomerFluent
NameOfCustomer(string Name)
{
obj.FullName = Name;
return this;
}
public CustomerFluent Bornon(string
Dob)
{
obj.Dob = Convert.ToDateTime(Dob);
return this;
}
public void StaysAt(string Address)
{
obj.Address = Address;
}
}
Now your client code is simple, nice and FLUENT as in the
below code.
customer.NameOfCustomer("Shiv")
.Bornon("12/3/1075")
.StaysAt("Mumbai");
I have seen four visible uses of fluent interfaces:-
LINQ Queries
var x = context.Users.Select(u
=> new { u.Id, u.Name });
Unit testing
Assert.AreEqual(obj.Expected,obj1.Actual);
Mock testing
Container.GetMock()
.Setup(s
=> s.Save(new Person()))
.Returns(true)
.Verifiable();
DSL (Domain specific language)
DSL is a language for simple users who do not understand
programming. So they can type something in simple English as shown below. This
will be parsed and checked for syntaxes. Later this sentence can be mapped to a
internal fluent interface statement.
task "warn if website is
not alive":
every 1.Hour
starting now
when WebSite("http://www.questpond.com ").IsAlive is
false
then:notify "admin@example.org", "site
down!"
Below is the code of the Fluent interface statement to which
the above DSL can map.
new FluentTask("alert if
site is down")
.Every( TimeSpan.FromMinutes(3) )
.StartingFrom( DateTime.Now )
.When(delegate
{
return WebSite("http://www.questpond.com").IsAlive
== false;
})
.Execute(delegate
{
Notify(“admin@example.org”,
“site down!”);
});
Are Fluent interfaces always good?
If you are creating fluent interfaces for developers then probably you are wasting time. Developers are consistent with creating objects with the new keyword and setting properties. Even if you create something simple for them they are consistent with certain consuming methodology and you will find you are adding more complexity than simplifying it.
Second thing we need to understand that we need to write
more amount of code to create fluent interfaces. As you saw in the previous
code I created a separate class for making interfaces simplified.
There are very few instances when you need fluent
interfaces, below are few of them:-
- During UNIT testing when the developers are not full fledged programmers.
- You want your code to be readable by non-programmers so that they can understand if the code is satisfies their domain logic.
- You are component seller and you want to stand out in the market as compared to the others by making your interfaces simpler.
- You are creating a DSL language and this language is mapped with fluent interface statements.
