Named parameters in Java
Creating a method that has many parameters is a major sin. Whenever there is need to create such a method, sniff in the air: it is code smell. Harden your unit tests and then refactor. No excuse, no buts. Refactor! Use builder pattern or even better use Fluent API. For the latter the annotation processor fluflu may be of great help.
Having all that said we may come to a point in our life when we face real life and not the idealistic pattern that we can follow in our hobby projects. There comes the legacy enterprise library monster that has the method of thousands parameters and you do not have the authority, time, courage or interest (bad for you) to modify … ops… refactor it. You could create a builder as a facade that hides the ugly API behind it if you had the time. Creating a builder is still code that you have to unit test even before you write (you know: TDD) and you just may not have the time. The code that calls the monstrous method is also there already, you just maintain it.
You can still do some little trick. It may not be perfect, but still something.
Assume that there is a method:
public void monster(String contactName, String contactId, String street, String district, . Long pT)
The first thing is to select your local variables at the location of the caller wisely. Pity the names are already chosen and you may not want to change it. There can be some reason for that, for example there is an application wide naming convention followed that may make sense even if not your style. So the call:
monster(nm, "05300" + dI, getStrt(), d, . , z+g % 3L );
is not exactly what I was talking about. That is what you have and you can live with it, or just insert new variables into the code:
String contactName = nm; String contactId = "05300" + dI; String street = getStrt(); Street district = d; . Long pT = z+g % 3L; monster(contactName, contactId, street, district, . ,pT );
or you can even write it in a way that is not usual in Java, though perfectly legal:
String contactName, contactId, street, district; . Long pT; monster(contactName = nm, contactId = "05300" + dI, street = getStrt(), district = d, . ,pT = z+g % 3L );
Tasty is it? Depends. I would not argue on taste. If you do not like that, there is an alternative way. You can define auxiliary and very simple static methods:
static T contactName(T t) < return T;>static T contactId(T t) < return T;>static T street(T t) < return T;>static T district(T t) < return T;>. static T pT(T t) < return T;>monster(contactName(nm), contactId("05300" + dI), street(getStrt()(, district(d), . ,pT(z+g % 3L) ); The code is still ugly but a bit more readable at the place of the caller. You can even collect static methods into a utility class, or to an interface in case of Java 8 named like with , using , to and so on. You can statically import them to your code and have some method call as nice as:
doSomething(using(someParameter), with(someOtherParameter), to(resultStore));
When all that is there you can feel honky dory if you answer the final question: what the blessed whatever * is parameter pT .
( * “whatever” you can replace with some other words, whichever you like)
Named parameters in Java (updated)
Creating a method that has many parameters is a major sin. Whenever there is a need to create such a method, sniff in the air: it is a code smell. Harden your unit tests and then refactor. No excuse, no buts. Refactor! Use builder pattern or even better use Fluent API. For the latter the annotation processor fluflu may be of great help. (Update: as of 2019. fluflu is deprecated. Use a more modern and handier solution: Java::Geci.)
Having all that said we may come to a point in our life when we face real life and not the idealistic pattern that we can follow in our hobby projects. There comes the legacy enterprise library monster that has the method of thousands of parameters and you do not have the authority, time, courage or interest (bad for you) to modify … ops… refactor it. You could create a builder as a facade that hides the ugly API behind it if you had the time. Creating a builder is still code that you have to unit test even before you write (you know: TDD) and you just may not have the time. The code that calls the monstrous method is also there already, you just maintain it.
You can still do some little trick. It may not be perfect, but still something.
Assume that there is a method
public void monster(String contactName, String contactId, String street, String district, . Long pT)
The first thing is to select your local variables at the location of the caller wisely. Pity the names are already chosen and you may not want to change it. There can be some reason for that, for example, there is an application-wide naming convention followed that may make sense even if not your style. So the call
monster(nm, "05300" + dI, getStrt(), d, . , z+g % 3L );
is not exactly what I was talking about. That is what you have and you can live with it, or just insert new variables into the code:
String contactName = nm; String contactId = "05300" + dI; String street = getStrt(); Street district = d; . Long pT = z+g % 3L; monster(contactName, contactId, street, district, . ,pT );
or you can even write it in a way that is not usual in Java, though perfectly legal:
String contactName, contactId, street, district; . Long pT; monster(contactName = nm, contactId = "05300" + dI, street = getStrt(), district = d, . ,pT = z+g % 3L );
Tasty is it? Depends. I would not argue on taste. If you do not like that, there is an alternative way. You can define auxiliary and very simple static methods:
static T contactName(T t) < return T;>static T contactId(T t) < return T;>static T street(T t) < return T;>static T district(T t) < return T;>. static T pT(T t) < return T;>monster(contactName(nm), contactId("05300" + dI), street(getStrt()(, district(d), . ,pT(z+g % 3L) ); The code is still ugly but a bit more readable at the place of the caller. You can even collect static methods into a utility class, or to an interface in case of Java 8 named like with, using, to and so on. You can statically import them to your code and have some method call as nice as
doSomething(using(someParameter), with(someOtherParameter), to(resultStore));
When all that is there, you can feel honky dory if you answer the final question: what the blessed whatever * is parameter pT.
( * “whatever” you can replace with some other words, whichever you like)
Named parameters in Java (updated)
Creating a method that has many parameters is a major sin. Whenever there is a need to create such a method, sniff in the air: it is a code smell. Harden your unit tests and then refactor. No excuse, no buts. Refactor! Use builder pattern or even better use Fluent API. For the latter the annotation processor fluflu may be of great help. (Update: as of 2019. fluflu is deprecated. Use a more modern and handier solution: Java::Geci.)
Having all that said we may come to a point in our life when we face real life and not the idealistic pattern that we can follow in our hobby projects. There comes the legacy enterprise library monster that has the method of thousands of parameters and you do not have the authority, time, courage or interest (bad for you) to modify … ops… refactor it. You could create a builder as a facade that hides the ugly API behind it if you had the time. Creating a builder is still code that you have to unit test even before you write (you know: TDD) and you just may not have the time. The code that calls the monstrous method is also there already, you just maintain it.
You can still do some little trick. It may not be perfect, but still something.
Assume that there is a method
public void monster(String contactName, String contactId, String street, String district, . Long pT)
The first thing is to select your local variables at the location of the caller wisely. Pity the names are already chosen and you may not want to change it. There can be some reason for that, for example, there is an application-wide naming convention followed that may make sense even if not your style. So the call
monster(nm, "05300" + dI, getStrt(), d, . , z+g % 3L );
is not exactly what I was talking about. That is what you have and you can live with it, or just insert new variables into the code:
String contactName = nm; String contactId = "05300" + dI; String street = getStrt(); Street district = d; . Long pT = z+g % 3L; monster(contactName, contactId, street, district, . ,pT );
or you can even write it in a way that is not usual in Java, though perfectly legal:
String contactName, contactId, street, district; . Long pT; monster(contactName = nm, contactId = "05300" + dI, street = getStrt(), district = d, . ,pT = z+g % 3L );
Tasty is it? Depends. I would not argue on taste. If you do not like that, there is an alternative way. You can define auxiliary and very simple static methods:
static T contactName(T t) < return T;>static T contactId(T t) < return T;>static T street(T t) < return T;>static T district(T t) < return T;>. static T pT(T t) < return T;>monster(contactName(nm), contactId("05300" + dI), street(getStrt()(, district(d), . ,pT(z+g % 3L) ); The code is still ugly but a bit more readable at the place of the caller. You can even collect static methods into a utility class, or to an interface in case of Java 8 named like with, using, to and so on. You can statically import them to your code and have some method call as nice as
doSomething(using(someParameter), with(someOtherParameter), to(resultStore));
When all that is there, you can feel honky dory if you answer the final question: what the blessed whatever * is parameter pT.
( * “whatever” you can replace with some other words, whichever you like)