Moq, Ninject, Fluent NHibernate styled library?

This is a brain storming question. Any c开发者_JAVA百科omments would be appreciated.

Recently I've observed a few source frameworks with a pattern similar to each other.

Moq

mock.Setup(framework => framework.DownloadExists("2.0.0.0"))
    .Returns(true)
    .AtMostOnce();

Ninject

Bind<IService>().To<RedImpl>().WhenMemberHas<RedAttribute>();

and Fluent NHibernate

   HasManyToMany(x => x.Products)
     .Cascade.All()
     .Table("StoreProduct");

I've noticed that they are all related to some sort of configuration. And it is more convenient to use compared to normal property-setting configuration.

I can tell I like this style, but can't figure out exactly why.

Can anyone tell me what advantage it has and when this style would be useful? Also, Is there a name for such a style? How is this implemented under the hood? If there is a tutorial on how to write Moq-styled, that would be much appreciated.

Update

Thanks for all the help. Now that I know this style is called Fluent Interface, is there any tutorial on how to create a sample Fluent interface?

---

The pattern is called Fluent Interface, and is described in greater detail at http://www.martinfowler.com/bliki/FluentInterface.html

It's generally best used when a full-on domain specific language for a task is overkill. Basically, you return the object that you are manipulating in each of the methods you write, and try to make the method names closely match the intent.

Though not necessarily connected, you may wish to compare the Builder pattern for an alternate approach to building complex objects, as some of the motivating scenarios are similar.

---

It is called a Fluent interface

The main advantage of this style is that you can easily read and write the code for building complex objects.

---

They are fluent interfaces and are generally used to create small DSLs for some task (such as configuration). They have advantages over text since they can be type-checked by the compiler.

As an example, many IoC containers can be configured using xml - this has some advantages such as easy deployment of configuration modifications, but is brittle in the event of some refactorings such as type renames.