File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Avoiding Monster Constructors Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Avoiding Monster Constructors" Watch "Avoiding Monster Constructors" New topic
Author

Avoiding Monster Constructors

Jeffrey Hunter
Ranch Hand

Joined: Apr 16, 2004
Posts: 305
Hey All,
I'd like your opinions on the problem of monster constructors. That is, constructors which receive a large number of parameters. For example, consider an Employee class, which models data from a database. The employee table in the database has approximately 25 fields (all of which are pertinent and should exist in every Employee instance). Now, a constructor with 25 parameters is certainly a beast which I'd like to avoid. The other option is to use setXXX methods to initialize instance variables, but of course, this strategy has its own drawbacks. What would your strategy be?

Thanks for your input.
Chris Stehno
Ranch Hand

Joined: Feb 26, 2001
Posts: 180
I'd say you want to try to group some of those properties of an Employee into other objects that could then be passed into the constructor.
Also think about whether or not all of those properties really need to be in the constructor. Are there default values that could be set in the constructor and over-ridden by setters if necessary?
Some design philosophies say that nothing (or very little) should be passed to a constructor, other say that only things that you actually need to create the object should be passed... and I have seen others that use the monster constructors.
The example is a little vague so it is hard to nail down a hard answer... but I generally lean towards putting as little as possible into the constructor.

Hope this helps.


- Chris Stehno, SCPJ
Scott Dunbar
Ranch Hand

Joined: Sep 23, 2004
Posts: 245
I would agree that, while I have seen a mega constructor, I'd strongly avoid it. You're correct that having 25 setters may not be a great setup but it is pretty standard. Your bean, assuming that you use Java been like naming conventions, will be useable in, for example, JSPs in a very easy way.

Also, if your bean implements a little bit of business logic it is far simpler to have the setter methods than a single constructor. One example is if you have a "dirty" flag in your objects. Say you have some collection of Employee classes. Your GUI allows a user to update one or more of these. When the GUI user is done editing maybe they would hit a "Save" button. Now, because you had individual setters you can ask each class if it has been modified. If so you can save it back to the DB.

This is an example when the bean really implements a little bit of business logic behind the scenes.

Basically I'd encourage you to go down the setter route. Yes, it is a pain but it encourages better encapsulation and it just might help alot in the future.


<a href="http://forums.hotjoe.com/forums/list.page" target="_blank" rel="nofollow">Java forums using Java software</a> - Come and help get them started.
Jeffrey Hunter
Ranch Hand

Joined: Apr 16, 2004
Posts: 305
Thanks, guys. I'm thinking about breaking up these 25 fields into logical components. For example, some of the fields indicate an employee's preferences, so a seperate Preferences class might be an idea here to encapsulate that data. The essential fields (e.g. firstname, lastname, ssn, etc.) will be part of the Employee constructor. Other fields really do not make sense in their own class, so I will most likely use setters to initialize these. Thanks again for the insight!
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

If no beans are involved, I would prefer one monster over 25 minimonsters.

Perhaps you may pass a ResultSet as parameter, and examine it in the class?
Would be one parameter.

When the database holds 25 values, I don't see a reason to split them into groups.
This will only confuse.

A monster-table is best represented by a monsterclass.
[ October 05, 2004: Message edited by: Stefan Wagner ]

http://home.arcor.de/hirnstrom/bewerbung
Mark Patrick
Ranch Hand

Joined: Feb 22, 2004
Posts: 51
I suppose you could also pass the values in a Collection. Maybe a Map?


Mark Patrick<br />SCJP 1.4
Simon Baker
Ranch Hand

Joined: Sep 09, 2004
Posts: 57
I would strongly advise against using a Collection object for this purpose.
This would simply move the verbosity one step further from the constructor, thus increasing confusion. Also, type checking would be done at run time rather than compile time. This is bad - always try to ensure that any error would be caught as early as possible, and certainly always at compile time rather than runtime if you can - this is the reason for the addition of Generic Types in Tiger.
 
GeeCON Prague 2014
 
subject: Avoiding Monster Constructors