At work I've been porting some Java code over to ASP.NET, and it makes extensive use of method chaining. For example:


What's your concensus on this as a sensible technique? I'm familiar with the justification behind it (e.g. Martin Fowler et al), but personally I found it cumbersome and tedious for the following reasons:

• It makes using properties in C# more difficult.
• Every setter and getter has to return "this".
• It just seems to trade source complexity in one area for another.

/me waits to get burned

It's all preference, but I'd probably have that written like this using an object initializer list and properties:

 

It just is cleaner and makes more sense to me. I'm not a big fan of method chaining for object creation like this because it doesn't make much logical sense to me. Why would a method that is supposed to set a value also returning the object I'm calling it on? That seems very odd and broken to me.

 

I use it when it makes sense to, i.e.
but anything more involved seems like it would be cumbersome and confusing.

In general it is bug prone. If any of the methods returns a null reference, for w/e reason, the next call in the chain will throw a NullReferenceException. For object initialization, the method Nick presented is far more preferable to me.

If you don't like it, don't use it. Let the people who like it, use it.

This technique (it's name is fluent interfaces) can save some space and provide more clarity if applied carefully. Carefully as in, not suddenly invoking a method that returns another object, so the last two lines would apply to an IBar whereas the first few lines configure an IFoo object ;)

But it can turn a difficult configuration into a breeze. For example, in my unit tests NMock allows me to write:


Imagine what a mess that would make if I wanted to tell NMock through some traditional interfaces and methods how to behave and what to look for.