You can simply return the first parameter of the extension method. (The this parameter.)

As you can't return 'this'. How would you implement your builders as static ext methods?

It seems most people use builders only as testing tools, but why keep all nice things in test-code only? Object creation is needed in production code, too.

Especially, if you care to read the observations in the article I mentioned, fluent builders are very useful streaming tools and make the data flow (possibly through transformers) in a maintainable and efficient way.

This pattern certainly has its uses. On the other hand, sometimes it might be a dependency problem: you cannot depend on the GetBuilderFor class without depending on all classes it has builders for.

Another trick is to make the builder an inner class of the class it is building. If the static method for accessing the builder is named "with", the building sentence becomes:

Car car = Car.with().model("Model").year(2009).build();

(from http://web.sysart.fi/developer/articles:nested_fluent_builder)

You provide Machinist with blueprints on how your object might normally be constructed:

Car.blueprint do
  year 2009
  manufacturer
  model
  description { Sham.description }
end

Then, you can ask Machinist to build an object and only be as specific as you need to for your test:

regular_car = Car.make
old_car = Car.make(:year => 1970)
old_audi = Car.make(:year => 1970, :manufacturer => audi)
nondescript_car = Car.make(:description => nil)

The blueprints are completely findable because they are (by convention) kept in one file, and the "make" method is on the domain class itself (just like "new" and "create").

Might have to give that a try out and see what it's like.

Thanks for the link.