> Okay, so you prefer code looking like:
> p = new SomePOJO ("bla", null, null, null, null, "bli", null,
> null, null);
>
> to code looking like:
> p = new SomePOJO ();
> p.setBla("bla");
> p.setBli("bli");
>
> I must say, I prefer the latter.
I prefer the CDI one.
Take two cases:
In a normal environment (ie where the container provides the dependencies),
the class will be instantiated by the container, so you wont be writing "p =
new SomePOJO (...". So it doesnt matter which is used, as you'll never see
it!
Now consider an environment where someone (who probably has no idea about
james's code) is using a component in their own code without DI. My
argument is that with CDI they are less likely to miss a dependency. The
dependencies are listed in an obvious place - the (only) constructor. They
have to provide them. They dont have to go find documentation that says:
"you must set bla, and bli after creating the class. You can set other
things, but they're optional."
CDI makes sense to me. The constructor is where the initialisation of the
object takes place, and you can provide initiailisation parmaeters. The
constructor is only called once, so dependencies can easily be mate
immutable. Using CDI ensures that once an object exists, it is usable.
There is no easy way to determine what state an SDI object is in. Therefore
it seems logical that it is the place to introduce hard dependencies.
> >
> > Another way of avoiding "parameter bloat" is to identify those
> parameters
> > common to many of an application's Classes and gather them together in a
> > single Class so that instances can be injected as a single object.
> >
>
> Sure this works, but unfortunately have the effect that classes
> are created
> for the sole purpose as being place-holders. This leads to a more
> complicated
> class-hierarchy. Which IMO is to be avoided. Again KISS.
Really? I thought this was the main principle of object orientation -
encapsulation. You take a bunch of related things, and bundle them together
inside an object. Say like, a person (could have a name, date of bith, etc)
or a CoreServices (could provide logging, configuration, etc)!
>
> > The key point is that CDI does not force us to deal with a n*n-1
> > constructor problem. There are a number of patterns that can be
> applied to
> > avoid this and the associated "parameter bloat" problem.
> >
>
> Unfortunately all these patterns to deal with parameter bloat
> introduces more
> complexity and are thus violating the KISS principle.
I would argue against that. KISS doesnt mean do it in the least number of
classes, or do it in the least number of calls. It means "Keep It Simple
Stupid". Minimising the number of classes might contribute to this, but i
think the biggest factor is making it easy to understand, and follow.
Providing a CDI subclass of each SDI class is simple. Subclass with one
constructor. If you name it appropriately so that people can find it, then
i dont think this violates KISS in any way!
> I agree that we should not focus on any given container.
> Apparently we cannot
> agree upon which concept JavaBean/CDI is the way to go, so I then move in
> favour of supporting both. That way we can run in any POJO container. As
> someone (sorry forgot who) posted earlier this is quite easy as the CDI
> constructor can be implemented like:
>
> SomePOJO (String a, String b, String c, String d)
> {
> this();
> setA(a); setB(b); setC(c); setD(d);
> }
>
> Alongside the mandatory no-args constructor.
>
AFAIK this wont work, as CDI relies on a constructors to determine
dependencies. If there is a no-argument constructor, then it will determine
that there are no dependencies! If you support both, then you will have to
extend the classses to make a CDI version:
public class SomePOJOCDI{
SomePOJOCDI (String a, String b, String c, String d)
{
super();
setA(a); setB(b); setC(c); setD(d);
}
}
Daniel.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
