I believe it is called 'method chaining', and personally, I don't like it. the problem comes when one method fails or returns a null. you then try and call a method on what is basically a null object, getting a NPE. This masks the real problem, and makes fixing things harder.
there may be some minor efficiency/memory gains for not creating temporary references to the intermediate objects, but those will be offset by the time lost beating your head against the wall trying to figure out where your code is failing and why.
That's just my 2cents.
Also, please check your private messages for an important administrative matter. Thanks
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Generally, as a coding style, I look askance at any of my developer that does this, although I let it slide if there are no other issues. From a performance persepctive, both ways are equal. Internally, Hotspot will "optimize" example 1 and example 2 to work like example 3. The only reason I prefer example 1, is because it improves readability and makes it easier to debug. Well sometimes example 2 improves readability.. It's kind of a when you see it you know it thing.
For example. I would find this easier to debug and read
Jayesh A Lalwani wrote:Yeah it's called "showing off" :p
Hardly. It's considered quite normal where I work. We generally consider method chaining to be more readable than the non-chained alternatives. Bear in mind that "readable" often boils down to "it looks like I expect it to look like", and is thus highly subjective, based on what each person or group is used to. But from my perspective, it improves readability by removing visual noise - I already know what object we were working on, and I don't need its name restated over and over (and over and over...).
fred rosenberger wrote: the problem comes when one method fails or returns a null. you then try and call a method on what is basically a null object, getting a NPE. This masks the real problem, and makes fixing things harder.
Yes, this is the one big problem with the style. You know that one of those methods is returning null, but can't tell which one. It's easy to find out if you can reproduce the problem in a debugger, but it's more of a pain if you're looking at an error log in production. It's a pity that Java doesn't support putting a horizontal position as well as a line number into a stack trace - then this sort of problem would be trivial to resolve.
Method chaining is best suited if the methods return type is void.
Otherwise its difficult to debug and understand.
Joined: Mar 05, 2008
sandy chops wrote:Method chaining is best suited if the methods return type is void.
Method chaining is impossible if the return type is void. In Java under its current rules at least. I think there was a Project Coin proposal to allow any void method to return itself, instead, implicitly. But this proposal was not adopted.
sandy chops wrote:Otherwise its difficult to debug and understand.
Really, it seems trivially easy to understand. The problems with debugging are there, but have little to do with the return type as far as I can tell.
Incidentally, method chaining is a key component of an API style which Martin Fowler calls a Fluent interface, which has been increasingly popular in the last few years.
One issue I have not seen mentioned here yet is the possibility that one of the chained methods will return a null, throwing a null exception, often crashing your program. Of course, if you just put the statements one after the other without chaining and without testing for null, the same thing will happen -- but you'll be able to put a breakpoint in the middle of things to stop them and see what's going on. I haven't actually tried to put a breakpoint in the middle of a line in Eclipse, but don't expect it would work.
I myself don't think it's bad or good BY ITSELF. Whether it is more readable likely depends on how the methods' functions are related, how many different return types are involved, whether all the steps make sense together, whether the usage is extreme (20 uses at once? 50?) and, yes, personal preference. It seems obvious the book you were reading has a bias ("more experienced programmers...", no doubt printed in a deep, wise font as though spoken by Morgan Freeman). But I think considering pluses and minuses, even left open-ended, is more use to practically all readers than just stating things as fact for which there doesn't seem to be much basis.
Ralph Cook wrote:One issue I have not seen mentioned here yet is the possibility that one of the chained methods will return a null
That's been discussed in three of the posts already.
Joined: Sep 22, 2011
This was my first post and I appreciate everyone's comments. I was astounded by how quickly the first response was posted. I had planned on checking back in a couple of days, but before I could logout I had my first response. I have a much better understanding of the pros and cons. I am glad I asked the question instead of just letting it pass as a curiosity. Thanks again to all of you.