What are your opinions on method chaining? I feel that I’m overusing it; pretty much every method I’m creating now returns the current object. I’ve looked around on Google and found a few discussions on the topic though they don’t really have a decisive answer. My code looks something like this:
I think it depends on your code style. I personally never method chain at all, but its not like I don’t like it. I just never think about using it. If your code becomes way too cluttered to read, then you know its time to stop, but if you can still read your own code and you’re not releasing it to someone else, why bother?
I don’t believe there is a definitive answer as this is one of those subjective issues.
[quote]Are there any more cons? Can method chaining be overused? Could it be considered bad practice?
[/quote]
Like all ‘patterns’ method chaining can be both a boon and a curse, it has it’s place but can be abused, I certainly wouldn’t be having every method returning the current object as you suggested. My personal rule-of-thumb is to use method chaining for immutable objects (such as a vector class) or builders where there are lots of calls to ‘configure’ an object.
On the subject of the problem of debugging such code: if you are using method-chaining a good technique is to put each method invocation on a separate line to make it easier to set breakpoints of step through the code in the debugger. Eclipse (and presumably other IDEs) can be configured so that automatic reformatting honours this style of coding, here’s a good blog article I found:
It can be useful in certain APIs where you are manipulating the same object in many ways – see jQuery or LibGDX vector math.
But it can also create an inconsistent API. If everything returns “this”, what about methods that need a meaningful return statement?
As a rule of thumb, IMHO if you don’t need it then don’t use it, and when you do use it, use it scarcely. Most of the time if you have tons of consecutive method calls on the same object, it might just be a sign of code smell.
The only real instance I would use method chaining is if the next method required an action from the first one otherwise you then have to update the object which is annoying.
I like this advice. In future I’ll stick to this, and at the moment I’m working on a library which does require a series of subsequent calls to configure a series of states, so I’ll start to do some refactoring and I’ll think carefully about what should/shouldn’t be chained.
I think its use is justified in the Builder pattern and for vecmath. The builder pattern itself is ‘only’ justified by the lack of named method/constructor arguments in Java.
I read somewhere that a future Java version would support method chaining by default on non-static methods with a void return type. I wonder whether it survived Project Coin…
I read somewhere that the idea of doing just that was put forward to oracle but it was declined because it would take a lot of work and “wasn’t very object orientated”. Sadly a can’t find the quote.
I feel that method chaining should be avoided unless you are creating clear and unambiguous “English sentences” (for lack of a better term). Borrowing from jmguillemette’s example, I would implement special methods explicitly stating that they return the object. From what was given:
Model.getMatrix().rotateX(15).translate(0,1,-1);
only the getMatrix() method is clear in what it is doing. For method chaining, I would change it to the following:
The rotateXAndReturnMatrix() and translateAndReturnMatrix() methods would be designed in the following ways:
Matrix rotateXAndReturnMatrix( int intValue ) {
this.rotateX( intValue );
return this.getMatrix();
}
Matrix translateAndReturnInstance( int intValue01, int intValue02, int intValue03 ) {
this.translate( intValue01, intValue02, intValue03 );
return this.getMatrix();
}
One could (and probably would) abbreviate these function names while also adhering to a coding convention: rotateX_R() and translate_R() would do the trick.
I think this is fine too, so long as you establish a coding convention for method chaining and never deviate from it. However, this would mean not using it for other purposes which would probably be too restrictive. I would create a new method with the necessary number of parameters and use that instead. This makes the code explicit in what it is doing and meanwhile allows method chaining to be used for whatever you want so long as the methods you are calling have been named in a way where compounded statements are 100% clear in what is happening to the data.
But when you are method chaining, isn’t it obvious you’re returning the object? I don’t understand the usefulness of rotateXAndReturnMatrix vs. rotateX. Just more to write out.
I have to agree with Opiop. Naming the method rotate is just as clear. Making the name longer or abbreviating the name is making the code harder to read. The only situation where it’d be unclear is if you chained several methods however one of those methods returned a different object, like in the example I posted in the original post.
