Re: Constructor of Component not DRY?
I't really does not matter much but I'm with Eelco and Johan on this. I prefer not to allow null values in the constructor. At least not if there is a constructor with fewer parameters that can be used instead. So I prefer to chain towards the simpler constructor if possible. On 8/24/07, Martin Funk [EMAIL PROTECTED] wrote: Eelco Hillenius schrieb: private component init(String, IModel) which can assume null arguments do the null checks in the constructor and forward to that method That's an option in general, though the disadvantage of that is that you can't use final fields. Anyway, for this case, if anyone cares, we can fix it in either way. I care. Is that enough anyones? mf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Constructor of Component not DRY?
Hi,
doing a little code reading and trying to understand what I read, I came
across org.apache.wicket.Component 's constructors.
To my eyes the two constructors look very much alike and I wonder why
they were not chained like this:
public Component(final String id)
{
this(id, null);
}
Which chapter in the Java schoolbook should I reread?
Martin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Constructor of Component not DRY?
i think that is grown this way, previously the model constructor did some
more i believe
Also i don't like this(id,null) because thats just horrible, If you call the
constructor with the model then the model shouldn't be null.
a nicer way could be
public Component(final String id, IModel model)
{
this(id);
this.model = wrapModel(model);
}
johan
On 8/23/07, Martin Funk [EMAIL PROTECTED] wrote:
Hi,
doing a little code reading and trying to understand what I read, I came
across org.apache.wicket.Component 's constructors.
To my eyes the two constructors look very much alike and I wonder why
they were not chained like this:
public Component(final String id)
{
this(id, null);
}
Which chapter in the Java schoolbook should I reread?
Martin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Constructor of Component not DRY?
hmmm... that would go against my taste of chaining from the constructor with the least parameters to the constructor with the most parameters. I'd just tend to chose the constructor with the most complex signature as the default constructor, doing the 'real' construction part of the object construction and the others chained towards it, using default or null values. I think I would typically do that too, though there are no hard rules for this, so it doesn't matter much in the end. Chaining like that doesn't work for constructors who assume that if their form is used, the passed in arguments are not null. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Constructor of Component not DRY?
just add a private component init(String, IModel) which can assume null arguments do the null checks in the constructor and forward to that method -igor On 8/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote: hmmm... that would go against my taste of chaining from the constructor with the least parameters to the constructor with the most parameters. I'd just tend to chose the constructor with the most complex signature as the default constructor, doing the 'real' construction part of the object construction and the others chained towards it, using default or null values. I think I would typically do that too, though there are no hard rules for this, so it doesn't matter much in the end. Chaining like that doesn't work for constructors who assume that if their form is used, the passed in arguments are not null. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
