Benefits and drawbacks of method chaining and a possibility to replace all void return parameters by the object itself

Question

I am mostly interested in Java, but I think it\'s a general question. Recently I\'ve been working with Arquillian framework (ShrinkWrap) that uses a lot of meth

Answer 1

You may like to read about Fluent Interface by Martin Fowler

Summarily

• do not chain method for the heck of it primarily because it breaks the Command Query Responsibility Segregation (CQRS) design principle.
• improve the api design by bringing it closer to the way business talks about those operations, think about them as internal DSLs
• try avoiding chaining independent methods because they pollute the API and may not be able to reveal intent to the client/maintainer of the code

Answer 2

The downside I have found of using method chaining is debugging the code when NullPointerException or any other Exception happens. Suppose you are having following code:

String test = "TestMethodChain"; test.substring(0,10).charAt(11); //This is just an example

Then you will get String index out of range: exception when executing above code. When you get into realtime situations and such things happen then you get at which line error has happened but not what part of chained method caused it. So it needs to be used judiciously where it known that data will always come or errors are handled properly.

It has its advantages too like you need not write multiple lines of code and using multiple variables.

Many frameworks/tools use this like Dozer and when I used to debug the code it I had to look through each part of chain to find what caused error.

Hope this helps.

Answer 3

It a considerable amount of work. Especially when inheritance is involved. Have a look at this great article about the builder pattern

It makes a lot of sense to implement it when you expect that clients will call several methods on the same instance sequentially e.g. builder pattern, immutable objects, etc. But in my opinion in most cases it doesn't really worth the extra effort.

Answer 4

If you prefer immutability and functional programming, you never return void.

A function without return value is only called for its side-effect.

Of course there are situations where this is not applicable, but a function returning void could be considered as a hint to try it in a different way.

Answer 5

Method chaining is a way to implement fluent interfaces, regardless of the programming language. Main benefit of it (readable code) tells you exactly when to use it. If there is no particular need for the readable code, better avoid using it, unless the API is naturally designed to return the context/object as a result of the method calls.

Step 1: Fluent Interface vs. Command-Query API

Fluent interface must be considered against command-query API. To understand it better, let me write a bullet-list definition of the command-query API below. In simple words, this is just a standard object-oriented coding approach:

• Method that modifies the data is called a Command. Command does not return a value.
• Method that returns a value is called a Query. Query does not modify the data.

Following the command-query API will give you the benefits like:

• Looking at the object-oriented code you understand what's happening.
• Debugging of the code is easier because each call happens separately.

Step 2: Fluent Interface on top of Command-Query API

But the command-query API exists for some reason, and it indeed, reads better. Then how do we have the benefits of both fluent interface and command-query API?

Answer: fluent interface must be implemented on top of the command-query API (as opposed to replacing the command-query API by the fluent interface). Think of a fluent interface as a facade over the command-query API. And after all, it's called fluent "interface" - a readable or convenience interface over the standard (command-query) API.

Usually, after the command-query API is ready (written, probably unit-tested, polished to easily debug), you can write a fluent interface software layer on top of it. In other words, fluent interface accomplishes its functions by utilizing the command-query API. Then, use the fluent interface (with method chaining) wherever you want a convenience and readability. However, once you want to understand what's actually happening (e.g. when debugging an exception), you can always dig into the command-query API - good old object-oriented code.

Answer 6

Objects have attributes and methods. Each method fulfills a part of the overall purpose of the object. Some type of methods, like constructors and getters and setters, are performing the life cycle management of the attributes and the object itself. Other methods return the state of the object and its attributes. Those methods are normally non void.

Void methods come in two flavors: 1. concerning the life cycle management of the object or the attributes. 2. having an output that is completely handled within the method and should not cause any state of change anywhere else.

ad 1. They belong to the internal working of the object. ad 2. The information of the parameters is used to execute some work within the method. After the method has completed has there been no change in effect on the object itself nor on the internal status of one of the parameters.

But why should you make a method returning void and why not for instance a boolean (success or not)? The motivation for a method to return void (like in a setter) is that the method is intended to have no side effect. Returning true or false might be a side effect. Void implies that the method has no side effect when the method is executed as designed. A void method returning an exception is good, because an exception is not a side effect of the normal processing of a method.

A method returning void implies that it is by definition an isolated working method. A chain of void methods is a chain of loosely coupled methods, because no other method can rely on the outcome of its predecessor as no method has any outcome. There is a design pattern for this, namely the Chain of Responsibility design pattern. Chaining different loggers is a traditional example and the call to the subsequent filters within the servlet api.

To chain void methods in a meaningful way implies that the shared object on which those methods work is after each step in a state that is understandable by the void method working on the object. All subsequent calls may not rely on the outcome of its predecessor nor influence the working of the calls after its own call. The easiest way you can ensure that is by not letting them change the internal state of the object (like the logger example), or let each method change another part of the internal state of the object.

Void methods to be chained are in my opinion only those methods that have flavor 2 and share some type of processing. I would not chain the void methods concerning the life cycle of the class, because each method is a change of a different part of the whole state of the object. The presence of those methods can change over time with any change of design of the class, hence do I not advice to chain those methods. Furthermore are all exceptions thrown by the first type of void methods independent of each other, while you may expect that the exceptions thrown by the chained void methods of flavor 2 sharing some type of processing have something in common.