Named Parameters in Java – an Alternative
In the last installment of this blog I wrote about a way to fake Named Parameters in Java. As so often there are many ways to do this, so here comes another one.
Instead of static methods producing value objects for each parameter you can use a single parameter object that happens to be a builder:
The method signature would look like this:
-
void doSomething3(ParameterBuilder pb)
The usage looks like this:
-
doSomething3(new ParameterBuilder()
-
.name("Alfred E. Neumann")
-
.link("http://blog.schauderhaft.de")
-
.ultimateAnswer(42)
-
.tempFile("c:\\temp\\x.txt")
-
.zip(23)
-
);
and the builder itself like this:
-
public class ParameterBuilder {
-
-
private String link;
-
private String name;
-
private int answer;
-
private int zip;
-
private String file;
-
-
public ParameterBuilder name(String aName) {
-
name = aName;
-
return this;
-
}
-
-
public ParameterBuilder link(String aLink) {
-
link = aLink;
-
return this;
-
}
-
-
public ParameterBuilder ultimateAnswer(int anAnswer) {
-
answer = anAnswer;
-
return this;
-
}
-
-
public ParameterBuilder zip(int aZip) {
-
zip = aZip;
-
return this;
-
}
-
-
public ParameterBuilder tempFile(String aFile) {
-
file = aFile;
-
return this;
-
}
-
-
// … getters for the fields omitted.
-
}
In a sense this is even more similar to named parameters, since you can define default values in the builder, thereby making arguments optional. Also the order of arguments does not matter.
If you want to use the parameter object for more then transfering a bunch of values from one side of a method signature to the other you should consider actually creating an immutable object from you builder (or at least passing it as an implementation of an immutable interface)






[...] Named Parameters in Java – an Alternative (Schauderhaft) [...]
In some cases, for example constructors, it is worth making your parameter object implement Cloneable so it can be used to represent the internal state of the object. This also does away with problems of mutability as a defensive copy can easily be made.
Here is an example I used recently that uses this pattern:
http://java.net/projects/wadl/sources/svn/content/trunk/wadl/wadl-core/src/main/java/org/jvnet/ws/wadl2java/Wadl2Java.java?rev=345
In this case it becomes more like a Memento rather than a Builder pattern.
my way of using Builder pattern in Java
Schauderhaft » Named Parameters in Java – an Alternative…
Thank you for submitting this cool story – Trackback from JavaPins…
@Jens
@Gerard Davison:
Wouldn’t it be nice to add an explicit build() method to your builders to be able to do validation there? Chances are, that with five or more optional parameters not all combinations are valid. So doSomething3() will also have to validate the parameters first, instead of just implementing the actual logic.
@Gerard Davison:
Your Parameters class isn’t thread-safe. Splitting it up into an immutable Parameters class and a mutable ParametersBuilder class might be preferrable depending on the use cases.
@Frisian
Of course this is an option which has some benefits, but of course also adds additional complexity.
In my little example I decided I don’t get a benefit from it and preferred the shorter, simpler code.
In a real use case this might be completely different.
…another alternative using Initializer block
https://gist.github.com/3360682
Complety agree with you, and acctually this is exactly what Accesors chain do in Lombok http://projectlombok.org/api/lombok/experimental/Accessors.html
a better alternative (with less code) would be the use of generics (and a static import):
public final class Param {
public static final T param(String name, T param) {
return param;
}
}
doSomething3(
param(“name”, “Alfred E. Neumann”),
param(“link, “http://blog.schauderhaft.de”),
param(“ultimateAnswer”, 42),
param(“tempFile”, “c:\\temp\\x.txt”),
param(“zip”, 23)
);
@Frank In this case the parameter names are just Strings without any meaning.
If this is sufficient for you, you might as well just use comments.
Or am I missing something?