Use of CDI 'only' limits a component to certain types of containers, for
example components with getter/setters patterns can have their dependencies
changed at runtime, I believe CDI limits a components reuse in other
projects.
A container should ideally be able to use any component by supporting
multiple component lifecycle types, Avalon describes/specifies a highly
detailed lifecycle, Pico container a very simple lifecycle. The point is
that a simple container cant manage a component with a complex lifecycle
where as a sophisticated container could/should host any component
lifecycle, therefore any component.
- A good component will allow containers to create/manage their lifecycle.
- A good framework will allow the management of multiple lifecycle types.
I think the spring framework is a strong move in that direction container
wise as the configurations are geared to wiring up components. This is
close to being (if not is) a dynamic way of describing lifecycles of any
type.
Simon
----- Original Message -----
From: "Daniel Perry" <[EMAIL PROTECTED]>
To: "James Developers List" <server-dev@james.apache.org>
Sent: Friday, April 08, 2005 11:02 AM
Subject: RE: SpringJames vs. JamesNG
> > 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
