• Post Reply Bookmark Topic Watch Topic
  • New Topic

what is better way to initialize attributes of object constructor or through method ?  RSS feed

 
amit taneja
Ranch Hand
Posts: 817
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what is better way to initialize attributes of
object constructor or through method ?

please give your reply !!

Regards
Amit !!!
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think there is no such thing as a better way in this regard.

In my case I decide depending on the number of attributes and which of those I must know at the moment of creating the object.

If the object I have to create has attributes whose value must be known during the construction process then I set them in the constructor, because they are necessary to initialize the object.

Other non-mandatory attributes I may set them in the constructor as long as they do not make the constructor signature too long and difficult to read and always that I consider them useful to know during the construction process.

Think of a POJO that represents a database entity that has 15 attributes. If you have to do the mapping yourself it is easier to set value by value using a set method, than preparing all the arguments to set them in the constructor.

In other cases you may not know the value for a particular attribute at the moment of creation of the object, and there are other cases where you can infer the value of an attribute from other attributes.

Think of a Swing component. You actually do not initialized all the attributes in the constructor, but only those that are really important to the component. You can set other attributes after the object has been created using set methods.
[ October 06, 2006: Message edited by: Edwin Dalorzo ]
 
amit taneja
Ranch Hand
Posts: 817
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
actually i m asking one thing is that intializing the object with lots of attribute in constructor is good practise or better to initialize them using setter method just after initialiing the object ?

I personally belive to intialize on setter but my friend's view is constructor is also good !! and we want to remove this conflict of better way to initialize the object attributes

kindly reply
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my opinion, a good object doesn't allow itself to be constructed in an invalid state. So all attributes necessary to make the object an object that is valid should be passed through the constructor.

If that creates a constructor that is too big, there are a number of options to pursue:

- split the class into several classes,
- use Parameter Objects,
- use the Essence pattern,
- probably others that would come to mind while working on the code

Does that help?
 
sven studde
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
actually i m asking one thing is that intializing the object with lots of attribute in constructor is good practise or better to initialize them using setter method just after initialiing the object ?


constructor = initialization
additional method call(e.g. setter) = inefficient
[ October 07, 2006: Message edited by: sven studde ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my opinion, a good object doesn't allow itself to be constructed in an invalid state.


This is a very strong point that I'll back up. (I try to never disagree with Ilja.) When possible, this assures that any reference you get to an instance of the class is going to be good.

There are also some pretty strong arguments that immutable classes are A Good Thing when possible. If you read up on that and buy into it, it tells you not to have setters at all.

The DTO with a zillion fields is always a tough one. We get them all the time at work when we accept large-grained buckets of data from other systems. A zillion-argument constructor would be impractical so for this category of objects we fall back on a zillion setters. Ick.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
This is a very strong point that I'll back up. (I try to never disagree with Ilja.)


That's disapointing. The most interesting discussions happen when we two disagree with each other...


There are also some pretty strong arguments that immutable classes are A Good Thing when possible. If you read up on that and buy into it, it tells you not to have setters at all.


Unfortunately, I agree...


The DTO with a zillion fields is always a tough one. We get them all the time at work when we accept large-grained buckets of data from other systems. A zillion-argument constructor would be impractical so for this category of objects we fall back on a zillion setters. Ick.


I'd actually argue that a DTO isn't really a fully fledged object - an object is defined by its behaviour, and a DTO is pure data. I'm not even convinced that it needs methods at all - why not just make the fields public? (Make them final, if you can.)
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not even convinced that it needs methods at all - why not just make the fields public? (Make them final, if you can.)


JavaBeans set such a bad example, didn't they?

The final idea is interesting. public final and unitialized? I'm pretty sure I wouldn't have come up with that.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, if you make them final, you *will* need a constructor, of course... :roll:
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yah, I haven't used final enough to remember it has to be initialized that way. I was thinking maybe it could be initialized once by any means but only once. Nope.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!