Method chaining to make code more readable when input parameters multiply
WANG Zi-Xiang
on 6 Jan 2026 at 17:12
You may have come across code that looks like that in some languages:
stubFor(get(urlPathEqualTo("/quotes"))
.withHeader("Accept", equalTo("application/json"))
.withQueryParam("s", equalTo(monitoredStock))
.willReturn(aResponse())
.withStatus(200)
.withHeader("Content-Type", "application/json")
.withBody("{\\"symbol\\": \\"XYZ\\", \\"bid\\": 20.2, " + "\\"ask\\": 20.6}")))
That’s Java. Even if you can’t fully decipher it, you can get a rough idea of what it is supposed to do, build a rather complex API query.
Or you may be familiar with the following similar and frequent syntax in Python:
import seaborn as sns
sns.load_dataset('tips').sample(10, random_state=42).groupby('day').mean()
Here’s is how it works: multiple method calls are linked together in a single statement, spanning over one or several lines, usually because each method returns the same object or another object that supports further calls.
That technique is called method chaining and is popular in Object-Oriented Programming.
A few years ago, I looked for a way to write code like that in MATLAB too. And the answer is that it can be done in MATLAB as well, whevener you write your own class!
Implementing a method that can be chained is simply a matter of writing a method that returns the object itself.
In this article, I would like to show how to do it and what we can gain from such a syntax.
Example
A few years ago, I first sought how to implement that technique for a simulation launcher that had lots of parameters (far too many):
lauchSimulation(2014:2020, true, 'template', 'TmplProd', 'Priority', '+1', 'Memory', '+6000')
As you can see, that function takes 2 required inputs, and 3 named parameters (whose names aren’t even consistent, with ‘Priority’ and ‘Memory’ starting with an uppercase letter when ‘template’ doesn’t).
(The original function had many more parameters that I omit for the sake of brevity. You may also know of such functions in your own code that take a dozen parameters which you can remember the exact order.)
I thought it would be nice to replace that with:
SimulationLauncher() ...
.onYears(2014:2020) ...
.onDistributedCluster() ... % = equivalent of the previous "true"
.withTemplate('TmplProd') ...
.withPriority('+1') ...
.withReservedMemory('+6000') ...
.launch();
The first 6 lines create an object of class SimulationLauncher, calls several methods on that object to set the parameters, and lastly the method launch() is called, when all desired parameters have been set.
To make it cleared, the syntax previously shown could also be rewritten as:
launcher = SimulationLauncher();
launcher = launcher.onYears(2014:2020);
launcher = launcher.onDistributedCluster();
launcher = launcher.withTemplate('TmplProd');
launcher = launcher.withPriority('+1');
launcher = launcher.withReservedMemory('+6000');
launcher.launch();
Before we dive into how to implement that code, let’s examine the advantages and drawbacks of that syntax.
Benefits and drawbacks
Because I have extended the chained methods over several lines, it makes it easier to comment out or uncomment any one desired option, should the need arise. Furthermore, we need not bother any more with the order in which we set the parameters, whereas the usual syntax required that we memorize or check the documentation carefully for the order of the inputs.
More generally, chaining methods has the following benefits and a few drawbacks:
Benefits:
- Conciseness: Code becomes shorter and easier to write, by reducing visual noise compared to repeating the object name.
- Readability: Chained methods create a fluent, human-readable structure that makes intent clear.
- Reduced Temporary Variables: There's no need to create intermediary variables, as the methods directly operate on the object.
Drawbacks:
- Debugging Difficulty: If one method in a chain fails, it can be harder to isolate the issue. It effectively prevents setting breakpoints, inspecting intermediate values, and identifying which method failed.
- Readability Issues: Overly long and dense method chains can become hard to follow, reducing clarity.
- Side Effects: Methods that modify objects in place can lead to unintended side effects when used in long chains.
Implementation
In the SimulationLauncher class, the method lauch performs the main operation, while the other methods just serve as parameter setters. They take the object as input and return the object itself, after modifying it, so that other methods can be chained.
classdef SimulationLauncher
properties (GetAccess = private, SetAccess = private)
years_
isDistributed_ = false;
template_ = 'TestTemplate';
priority_ = '+2';
memory_ = '+5000';
end
methods
function varargout = launch(obj)
% perform whatever needs to be launched
% using the values of the properties stored in the object:
% obj.years_
% obj.template_
% etc.
end
function obj = onYears(obj, years)
assert(isnumeric(years))
obj.years_ = years;
end
function obj = onDistributedCluster(obj)
obj.isDistributed_ = true;
end
function obj = withTemplate(obj, template)
obj.template_ = template;
end
function obj = withPriority(obj, priority)
obj.priority_ = priority;
end
function obj = withMemory( obj, memory)
obj.memory_ = memory;
end
end
end
As you can see, each method can be in charge of verifying the correctness of its input, independantly. And what they do is just store the value of parameter inside the object. The class can define default values in the properties block.
You can configure different launchers from the same initial object, such as:
launcher = SimulationLauncher();
launcher = launcher.onYears(2014:2020);
launcher1 = launcher ...
.onDistributedCluster() ...
.withReservedMemory('+6000');
launcher2 = launcher ...
.withTemplate('TmplProd') ...
.withPriority('+1') ...
.withReservedMemory('+7000');
If you call the same method several times, only the last recorded value of the parameter will be taken into acount:
launcher = SimulationLauncher();
launcher = launcher ...
.withReservedMemory('+6000') ...
.onDistributedCluster() ...
.onYears(2014:2020) ...
.withReservedMemory('+7000') ...
.withReservedMemory('+8000');
% The value of "memory" will be '+8000'.
If the logic is still not clear to you, I advise you play a bit with the debugger to better understand what’s going on!
Conclusion
I love how the method chaining technique hides the minute detail that we don’t want to bother with when trying to understand what a piece of code does.
I hope this simple example has shown you how to apply it to write and organise your code in a more readable and convenient way.
Let me know if you have other questions, comments or suggestions. I may post other examples of that technique for other useful uses that I encountered in my experience.
3 Comments
Time Descending
Two minor comments for consideration:
"extended the chained methods over several lines, it makes it easier to comment out or uncomment any one desired option, should the need arise."
Just want to point out that such commenting is accomplished by putting an ellipsis at the beginning of the line, not the % that would result in an error.
>> SimulationLauncher() ...
.onYears(2014:2020) ...
... .onDistributedCluster() ...
.launch()
Launched
"Furthermore, we need not bother any more with the order in which we set the parameters, whereas the usual syntax required that we memorize or check the documentation carefully for the order of the inputs."
Name/Value pairs can be input in any order, and I suppose it's feasible that all arguments can be made into Name/Value pairs so that order doesn't matter for any of them.
Thanks for sharing, this is really interesting. I find this style works pretty well for anything you think of as a pipeline - a chain of operations. This is quite common in data analysis - I see it all the time in code using pandas.
Personally, I don't love it for your specific example. If I were designing it, I would replace your methods with properties - this feels like more idiomatic MATLAB. I'd provide an option to stream the property values into the constructor as named args (like passing line properties when calling plot), or just set them after. Setting them after construction gives many of the same benefits as your design, though it is a bit more verbose:
launcher = SimulationLauncher();
launcher.Years = 2014:2020;
launcher.OnDistributedCluster = true;
launcher.Template = "TmplProd";
launcher.Priority = "+1";
launcher.ReservedMemory = "+6000";
launcher.launch();
I find the biggest wins for method chaining to be a) when they are methods that do stuff, not just set state (that's how my brain thinks after decades of MATLAB), and b) when it's a 1-liner. A 1-liner can nicely read left-to-right as a chain of operations.
Here's an example with pandas
result = (
df
.groupby("team", as_index=False)
.agg(total_points=("points", "sum"))
.sort_values("total_points", ascending=False)
)
A 1-liner can be good, but also gets out of hand if you need to set a lot of options in the method calls:
result = df.query("points > 8").groupby("team", as_index=False).agg(total_points=("points","sum")).sort_values("total_points", ascending=False)
I'd love to hear reactions to my thoughts. Thanks again for such an interesting discussion.
Those are really interesting observations, and the pandas remark enables me to relate the discussion to my previous article on encapsulating tables if one wishes to combine the method chaining technique with "table objects" in MATLAB the same way as in Pandas ;).
That being said, regarding your first remark, I agree that creating a method just for configuring an object (a method that "doesn't do anything real") may seem strange.
I think I've become reluctant to exposing object Properties. The day one wishes to have more sophisticated behaviour (say, expand a scalar input into a vector or matrix depending on the sizes of the other inputs) will require one to change the Property setter method, which can still be done, so it also works.
Another practical use of the method chaining technique happens when one wishes to use the same method several times in a sequence, like this:
launcher = SimulationLauncher() ...
.onYears(2014) ...
.onDistributedCluster() ...
.onYears(2016:2020);
where the years would be automatically concatenated instead of being replaced. I can think of examples where this can be very handy and where we'd still delay the final calculation only at the end when all the configuration has been settled.
That use of method chaining for configuring an object can also be useful in case the configurations happens in several steps, not all at once, in different parts of the code.
Hope that gives everyone some more ideas for practical uses in their own code!
Sign in to participate
