Method Chaining in Java [closed]

Answer 1

Method chaining is typically used with the Builder pattern, and you can see this in the StringBuilder class. Outside of that, method chaining can make the command and creation separation less clear, for instance should repaint() also be part of the fluent interface? Then I could have:

container.add(label).repaint().setMaximumSize(new Dimension(100,200)));

and suddenly the order of my calls becomes important which can get hidden in the method chaining.

Answer 2

You are really asking about the Law of Demeter

"Only talk to your immediate friends"

Note that the above link is a wonderful resource but you can spend a long time there and not get an answer you were looking for! :-)

Answer 3

Another reason I can think of is performance, or more precisely: don't pay for something you don't use. return this after each and every method isn't very costly, but still requires few extra CPU cycles and one CPU registry.

There was even an idea to add implicit return this to every method declaring void return value but it was rejected.

Answer 4

Although we can but guess as to the real reason, one of them could be that strictly speaking it's not very OO.

If you view methods as actions that represent an action of the modelled world, method chaining doesn't really fit into that picture.

Another reason could be the chaos that might ensue when you're trying to override a chained method. Imagine this situation:

class Foo {
   Foo chainedMethod() {...}
}

class Bar extends Foo {
   Foo chainedMethod() {...} //had to return Foo for Java versions < 1.5
   void doStuff();
}

So when you're trying to do new Bar().chainedMethod().doStuff(), it won't compile. And ((Bar)new Bar().chainedMethod()).doStuff() doesn't look very good, does it :)

Answer 5

Eh. There's readability arguments to be made in both directions -- there's such a thing as trying to put too much into a single line.

But honestly, I suspect here it's for historical reasons: pervasive "chaining" behavior hadn't really become popular or well-known when e.g. Swing was being developed. You could argue that it should've been added in later on, but things like that tend to create binary incompatibilities and other issues that Sun/Oracle have historically been extremely cautious about.

More recent JDK libraries -- see e.g. ByteBuffer for a major, well-known example -- have provided chaining behavior and the like, where it makes sense.

Answer 6

The reason behind not implementing method chaining would be some of the following:

• The biggest problem for Method Chaining is the finishing problem. While there are workarounds, usually if you run into this you're better off using a Nested Function. Nested Functions are also a better choice if you are getting into a mess with Context Variables.

• There's no guarantee that an object out of the chain will actually return a valid, non-null object. Also, debugging this style of code is often a lot harder since many *IDE*s will not evaluate the method call at debug time as an object that you can inspect

• It can get confusing when you're calling routines to other classes to pass arguments to one of the chaining methods, when there are a lot of parameters to pass mainly because the lines get very long

• There is also a performance issue, which will work hard on memory