Regards

You can download it here:
http://rabdullin.com/shared-libraries/

Fluent interfaces compliment an internal DSL’s behavior an the interaction between the language constructs that form the DSL.

Method chaining is simply returning the same instance out of the given method that you are invoking against that object.

Fluent interfaces enforce DSL’s through class delegation upon the architecture. Meaning I can’t invoke the addProduct() Method unless I have created an Order with a customer.

Make sense?

Fair enough.

I do agree that a fluent interface is difficult to read from the actual classes that make it possible. You really need to use the fluent interface to see how it works. Once you do that, then it’s easy to dive in and understand how the code is actually setup.

Whether or not this is an ample situation for fluent interfaces or not is actually a good question. With the original article by Bill, you had to do tricky assertions as my example above states. This is what motivated me to use a fluent interface. I suppose it was more of an example than anyhting else.

I wanted for the assertion to read more like a sentance than an assertion to make the code more soluable which is why I made it that way. I felt it was more concise than not using it.

Good points!

What I don’t like about fluent interfaces is that you don’t know from the looks of the code, what you are dealing with. It might include “fluent interface calls” as well as simple method calls on returned objects. Is it a reference to the object itself, a copy, another object? Or null? Which leads to the questing how one will track down a NullReferenceException (or other) in such a call chain.

Fowler (http://martinfowler.com/bliki/FluentInterface.html) had the folowing example of a fluent interface:

private void makeFluent(Customer customer) {
customer.newOrder()
.with(6, “TAL”)
.with(5, “HPK”).skippable()
.with(3, “LGV”)
.priorityRush();
}

This was a rewrite of some ugly sample code. That ugly code could have been improved by simply cleaning it up a bit. Some small helper methods could further help, e.g. the following fragment is just as clean as the above code:

private void makeBetter(Customer customer) {
Order o1 = CreateNewRushedOrder(customer);
AddLine(o1, 6, “TAL”);

AddLine(o1, 5, “HPK”, Options.Skippable);
AddLine(o1, 3, “LGV”);

}

No fluent interfaces needed. So why introduce a new pattern, thus add complexity, if it does not provide some additional value?

#2: Check class
Why rewrite
Check.Require(!string.IsNullOrEmpty(username), “username is required”);
to
Check.Parameter(username).WithMessage(“username is required”).IsNotNullOrEmpty();
?

What happened to
Guard.AssertNotEmpty(username, “username”, “username is required”);
?
Readable, concise, and consistent exceptions

Just my 0,02€.
AJ.NET

I will see about setting up a seperate Google Code repository for just this project. This way it isn’t tied specifically to my code repository.

I have a couple of things to do this afternoon so I may not get to this stuff till tomorrow anyways.

ttyl!

I can get you my classes later today if you wish, I’m in the middle of something right now.

Josh, Can you supply the classes you have been using so we can take a look? I would like to expand my classes a little more when I have a chance.

I think I am going to start a FluentDBC google group so we can move the discussion there perhaps? The comments on this thread are getting a little long.

What does everyone else think?