• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Avoiding Monster Constructors

 
Ranch Hand
Posts: 305
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 180
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Jeffrey Hunter
Ranch Hand
Posts: 305
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Ranch Hand
Posts: 1923
Scala Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I suppose you could also pass the values in a Collection. Maybe a Map?
 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic