Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Method Chaining  (Read 1038 times)
0 Members and 1 Guest are viewing this topic.
Offline Troubleshoots

JGO Knight


Medals: 36
Exp: 7-9 months


Damn maths.


« Posted 2014-01-02 12:43:03 »

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:

1  
object1.doSomething().doSomethingElse().doAnotherThing();

The cons that I've found are:

  • Can make code harder to read
  • Makes code harder to debug
  • Loss of a few bytes of memory for every return statement

To be honest, #3 is nothing major and #1 would only apply with something like this:

1  
object1.doSomething().thisMethodReturnsAnotherObject().doSomethingWithReturnedObject();

Are there any more cons? Can method chaining be overused? Could it be considered bad practice?

Why are all OpenGL tutorials written in Brainf**k?
Offline opiop65

JGO Kernel


Medals: 153
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #1 - Posted 2014-01-02 13:29:45 »

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?

Offline StrideColossus
« Reply #2 - Posted 2014-01-02 13:37:36 »

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.

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?

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:

http://blog.lckymn.com/2009/06/30/method-chaining-to-use-or-not-to-use/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline jmguillemette
« Reply #3 - Posted 2014-01-02 17:20:18 »

I like method chaining but only where it adds clarity.
So like anything its about making a call about when it appropriate.

I personally use method chaining when working with my matrix class.

Model.getMatrix().rotateX(15).translate(0,1,-1);

Order of these calls matter and they build on each other.

I most other situations in my code I dont use chaining cause i want it to be clear what im doing on each line. (and each line is a distinct function)

One might argument that the combination of chaining i do with my matrix class is also only 1 distinct function and thats why i chain them.

j.

-=Like a post.. give the author a medal!=-
Offline davedes
« Reply #4 - Posted 2014-01-02 18:14:07 »

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.

Offline lcass
« Reply #5 - Posted 2014-01-03 13:12:28 »

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.
Offline Troubleshoots

JGO Knight


Medals: 36
Exp: 7-9 months


Damn maths.


« Reply #6 - Posted 2014-01-03 14:24:39 »

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.

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.

Why are all OpenGL tutorials written in Brainf**k?
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #7 - Posted 2014-01-03 18:14:47 »

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...

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Troubleshoots

JGO Knight


Medals: 36
Exp: 7-9 months


Damn maths.


« Reply #8 - Posted 2014-01-03 22:16:48 »

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.

Why are all OpenGL tutorials written in Brainf**k?
Offline Ghidra

Senior Newbie


Medals: 3



« Reply #9 - Posted 2014-01-04 05:44:20 »

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:

Matrix someMatrix = Model.getMatrix().rotateXAndReturnMatrix(15).translateAndReturnMatrix(0,1,-1);

The rotateXAndReturnMatrix() and translateAndReturnMatrix() methods would be designed in the following ways:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
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 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 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.


Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline opiop65

JGO Kernel


Medals: 153
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #10 - Posted 2014-01-04 14:53:37 »

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.

Offline Troubleshoots

JGO Knight


Medals: 36
Exp: 7-9 months


Damn maths.


« Reply #11 - Posted 2014-01-04 15:55:31 »

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:

Matrix someMatrix = Model.getMatrix().rotateXAndReturnMatrix(15).translateAndReturnMatrix(0,1,-1);

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 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.

1  
object1.doSomethingWithObject1().returnObject2().doSomethingWithObject2();

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.

That wouldn't exactly work for what I want to do.

Why are all OpenGL tutorials written in Brainf**k?
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Riven (4 views)
2014-07-29 12:53:52

Dwinin (7 views)
2014-07-29 10:59:34

E.R. Fleming (21 views)
2014-07-29 03:07:13

E.R. Fleming (8 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (51 views)
2014-07-17 23:47:54
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!