This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
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?
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.
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.
Joined: Apr 16, 2004
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!
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.