This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Just want to know what is the best practice to reduce the number of input parameters to a java function?
I took over a piece of code, one java constructor function has 15-20 input parameters, including boolean, String data type, etc. Since we keep adding new parameters, we 'd better use other ways to reduce the number of input parameters?
Originally posted by Jeff Albrechtsen: You could use a factory pattern where you configure a factory then create the product
That actually sounds more like the Builder pattern to me.
An alternative is to simply introduce parameter objects: group parameters into their own classes. For example, instead of passing street, house number, zip code and city as separate objects, pass an Address object.
There are also some more advanced alternatives, but without knowing more about your code, it's hard to advice on which one to use.
If you want to know more about the general techniques of improving your code, I'd highly recommend reading "Refactoring" by Martin Fowler.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Michael L. Zhang
Joined: Jul 06, 2003
Thanks every one, the below is the piece of code, you can see, the last constructor takes a lot of input parameters. The java code to call the last constructor has to use a lot of input parameters. Any advice on this piece of code? The java file name is: Resource.java, which is a common object to hold status data and it is used every where in the application.
Going along with the earlier suggestion it looks like you need a class to send into the ctor. Maybe a class called ResourceConfiguration. You could get rid of all the existing ctors and just use one:
You could set up the ResourceConfiguration class to initialize all fields to null or some other meaningful default so the user only has to set the fields that deviate from the default value. The ResourceConfiguration class might be a good place to define standard constants if you have any (using static final fields).
Long arg lists start to get hard to manage cause you start to forget the order of the args. Since all of your args are either String or boolean it's pretty easy to get the order of the actuals wrong without the compiler noticing.
_M_ [ December 20, 2005: Message edited by: Mike Noel ]