

Named Parameters in Java - javinpaul
http://java.dzone.com/articles/named-parameters-java

======
jasonkolb
Wow this would make for some crazy code to try to read thru. I would be über-
pissed to trace thru code like this only to find all of these wrapper classes.
This is what Javadocs are for, it's much easier and cleaner just to document
your code as you write it.

~~~
tsewlliw
This. I'd do my best to make sure the authors contributions stopped. Type
safety obviously doesn't protect you the worst possibilities in software.

------
cpt1138
Wouldn't the Builder pattern address this issue? So you can do:

object.setName("Alfred E. Neumann") .setLink("<http://blog.schauderhaft.de>)
.setUltimateAnswer(42) .setTempFile("c:\\\temp\\\x.txt") .setZip(23);

~~~
devgutt
I think this way is better:

    
    
      o.doSomething({
        name : "Alfred E. Neumann",
        link : "http://blog.schauderhaft.de,
        ultimateAnswer: 42,
        tempFile: "c:\\temp\\x.txt",
        zip : 23});

~~~
javinpaul
another example of Builder pattern <http://goo.gl/NkAhE>

------
dhimes
Whoever wrote the original code is missing a major point in OOP: you should
(almost) never be passing in simple types. Create an object that holds the
data (class IDObject, for instance), and pass an instance of this class in for
the parameter. Then, the parameters are _de facto_ named in the data object.

This importance of this method is that it allows the you to update the
information passed in via the data object (when ID needs change, and they will
over the course of a project) without breaking the interface. And that's the
_point_ of it all.

~~~
TazeTSchnitzel
Never passing in simple types?

I don't know about you, but one of the reasons I like languages such as Python
and JavaScript is I don't have to create a wrapper object for every type I'm
using. The fact I had to, for instance, create URL and IP Address and such
objects in C# drove me crazy.

~~~
nessus42
Named tuples are nice in Python.

I wonder how easy it is, though, to modify a namedtuple constructor to do
argument validation and to allow for default field values.

~~~
TazeTSchnitzel
If you see how namedtuple is implemented, you'd realise it's extremely easy.

namedtuple uses eval(). It really shouldn't, since there are far better ways
to do what it does, but it does.

------
columbo
Interesting. But it looks like it is solving a problem with another problem.
The receiving class would then look like this:

    
    
        public void doSomething(Name name, Link link, UltimateAnswer ultimateAnswer, TempFile tempFile, Zip zip) {
            String name = name.name;
            String link = link.link;
            int ultimateAnswer = ultimateAnswer.ultimateAnswer;
            String tempFile = tempFile.tempFile;
            int zip = zip.zip;
        }
    

If the problem is "I don't like these SAME values being used all over the
place" then use DEFAULTS.

    
    
        o.doSomething1(); //defaults to "Alfred","c:\\temp",42,"shadurhaft.de",23
    

That or pass in an object. o.doSomething1(mySomethingObject);

If the values are genuinely different then the only way to solve this problem
is to validate the options (paths should be a valid file location and not a
website, websites should be a valid website etc) and then (possibly) pass in
an object instead of primitives.

I don't see encapsulation doing anything really, aside from increasing the
number of "junk" classed by about a hundred fold.

Why throw standard convention out the window?

~~~
peeters
I'm not sure I see the "another problem" you're referring to. Can you describe
the problem with the new implementation of doSomething()?

Also, I don't think the original problem was the same values being used all
over the place. The problem is how to be clear about which parameters you're
providing, and accepting static types and giving the type a simple way of
constructing it solves that.

~~~
jlgreco
The other problem is that

    
    
      int zip = zip.zip;
    

is just silly, even by Java's standards.

------
bchen
Since long parameter list is considered a code smell, people should be
discouraged from writing this kind of code anyways. Namely, this example from
the article is in fact a bad practice:

> o.doSomething1("Alfred E. Neumann", "<http://blog.schauderhaft.de>, 42,
> "c:\\\temp\\\x.txt", 23);

As other commenters have pointed out, I think the builder pattern is one of
the two solutions I would use. The other solution is to simply create an
object that represents the values to be passed in to the method. Consider:

    
    
      User user = new User("Alfred E. Neumann");
      user.setLink("http://blog.schauderhaft.de);
      user.setUltimateAnswer(42);
      user.setTempFile("c:\\temp\\x.txt");
      user.setZip(23);
      o.doSomething(user);
    

Even with named parameters, I would say the latter approach is still superior
than having a long parameter list.

~~~
yarrel
Named parameters would result in more readable, compact, and efficient code
compared to the latter approach.

But yes, long parameter lists (whether represented as argument structs or not)
generally indicate a problem.

------
pathdependent
Although the solution produces too many problems, I agree that named
parameters are highly desirable for readability and the prevention of bugs.
Have there been any proposals for Java 8 to included named parameters?

Edit:

* <http://openjdk.java.net/jeps/118> proposes run-time storing of parameter names -- not what is desired, but in the same ballpark.

* <http://web.archiveorange.com/archive/v/bobySzLnuDWgr47zqwU9> proposes named arguments for making clean code.

~~~
bad_user
The problem with named parameters is that suddenly method parameters become
part of your exposed API.

The other problem is that the compiler currently discards the parameter names,
so older binaries are not going to be compatible.

------
PaulHoule
It might be crazy but I like this kind of DSLization of Java a lot

~~~
bartonfink
I think it would really shine with IDE support. It probably wouldn't even be
that hard to do (famous last words). I think I'll take a stab at it.

I like it as well, and have done similar things by creating input/output
classes to use as "structs" when the list of parameters gets unweildy or when
I want multiple returns.

~~~
tkellogg
When "the list of parameters gets unweildy" and "I want multiple returns" are
to major indicators that you got some anti-patterns going on. I think the
refactoring that you need might a new class with a single responsibility.

~~~
gizmo686
Or they are indicators that you have experience in languages that allow such
designs, and would like java to introduce them. My biggest problem with java
is that it tried to be a single paradigm langues: object oriented. While it
was doing that, people worked on developing other methods. Concepts from these
other systems are beggining to creep into java. For example, generics are a
functional concept, as are lambdas which will be introduced in the next
version.

------
jebblue
I would not use a separate class per parameter though that is a clever
solution. It might hurt performance and it just feels a bit heavy.

For performance, clarity and reusability I would simply create a class that
holds the values needed. Add an @Entity tag and now it can be used as a
Hibernate persistence class too.

------
josemando
Coming back to Java after learning Objective-C made realize how named
parameters are awesome

~~~
SeanLuke
Objective-C doesn't have named parameters (that is, Lisp-like "keyword"
parameters). It has a hack which allows a method to be so named that it has to
be used in a named way. Named parameters can be in any order and may or may
not exist in the function call. Obj-C can't do this because its "names" are
actually just part of the method signature. It's fake.

~~~
sbmassey
It may be "fake", but it still has the property that this article was looking
for, in that it is obvious to the reader what each of the arguments being
passed to the method are for.

------
erode
I use named parameters in csharp, and they are nice, but they're not worth all
that extra effort. The code is now much more confusing.

------
x3eme
or you know, use an IDE!

~~~
jebblue
This is a good observation, people who seem to like named parameters strike me
as people who might code in plain text editors a lot. Nothing wrong with that
but an IDE makes things so much easier and faster.

~~~
Aykroyd
I think there's a kernel of truth to that but it's not entirely right. I use
Pycharm for my python coding and still like named parameters because it makes
clear at a glance what each parameter is in the function call. Otherwise, I'd
need to click through to each function definition or use the "show doc"
command to figure it out. It's much better to be able to scan through the code
and understand it without intervention from IDE features.

~~~
jebblue
I guess I could see that but it might take me a few thousand lines for it to
sink in. Makes sense stated the way you did. If you have to add a parameter
though then you have to locate all of the locations and update them. With an
object you just add the new field and its accessors if you want and then only
the new section of code interested in that new field would be changed; but
it's new so.

