--- Soren Hilmer <[EMAIL PROTECTED]> wrote:
> On Wednesday 06 April 2005 22:47, Steve Brewin
> wrote:
> > > No, I see (as you) JavaBean==POJO, but
> CDI!=JavaBean. And I
> > > prefer using the
> > > JavaBean approach instead of CDI.
> > > My concern is that CDI does not facilitate
> optional
> > > properties very well.
> > > If you have some POJO, with just 2 optional
> properties that
> > > will lead to 4
> > > constructors!! This is what I call constructor
> bloat.
> >
> > Many of my thoughts regarding a container for
> James are already recorded in
> > the mailing lists. I will not repeat them here.
> >
> > My interpretation of the CDI metaphor allows no
> tolerance for ambiguity.
> > There should be exactly one public constructor for
> a Class that encompasses
> > all possible parameters. Optional parameters may
> be passed into this
> > constructor as null. This is the contract a Class
> honours. As there is only
> > one constructor, there is no "constructor bloat".
> >
> Okay, so you prefer code looking like:
> p = new SomePOJO ("bla", null, null, null, null,
> "bli", null, null, null);
This is highly contrived. Constructor bloat is the
result of poor design. Sometimes integrating with
legacy software requires something like this.
Wrapping in an explicit public inner class makes it
quite clear.
The SDI folks are missing out on the bigger point.
Error handling. A CDI class _knows_ it is
correct/complete, by virtue of success of
construction. In SDI you have to constantly check
whether the object's state is up to par. Then your
business methods can/will throw all kinds of
Exceptions.
Doesn't sound quite that simple.
Gabor
Gabor Kincses
Running Mandrake Linux 10.0
__________________________________
Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun.
http://www.advision.webevents.yahoo.com/emoticontest
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
